This list is closed, nobody may subscribe to it.
2003 |
Jan
|
Feb
|
Mar
(3) |
Apr
(6) |
May
|
Jun
(14) |
Jul
(4) |
Aug
(19) |
Sep
(27) |
Oct
(7) |
Nov
(4) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(58) |
Feb
(20) |
Mar
(70) |
Apr
(93) |
May
(102) |
Jun
(130) |
Jul
(47) |
Aug
(61) |
Sep
(149) |
Oct
(160) |
Nov
(243) |
Dec
(94) |
2005 |
Jan
(199) |
Feb
(166) |
Mar
(276) |
Apr
(422) |
May
(289) |
Jun
(222) |
Jul
(306) |
Aug
(154) |
Sep
(72) |
Oct
(163) |
Nov
(113) |
Dec
(195) |
2006 |
Jan
(174) |
Feb
(94) |
Mar
(130) |
Apr
(45) |
May
(85) |
Jun
(115) |
Jul
(120) |
Aug
(111) |
Sep
(210) |
Oct
(56) |
Nov
(72) |
Dec
(30) |
2007 |
Jan
(56) |
Feb
(49) |
Mar
(35) |
Apr
(58) |
May
(83) |
Jun
(101) |
Jul
(46) |
Aug
(58) |
Sep
(47) |
Oct
(58) |
Nov
(55) |
Dec
(54) |
2008 |
Jan
(52) |
Feb
(21) |
Mar
(20) |
Apr
(49) |
May
(20) |
Jun
(37) |
Jul
(101) |
Aug
(49) |
Sep
(75) |
Oct
(152) |
Nov
(34) |
Dec
(63) |
2009 |
Jan
(90) |
Feb
(12) |
Mar
(88) |
Apr
(49) |
May
(36) |
Jun
(36) |
Jul
(52) |
Aug
(54) |
Sep
(19) |
Oct
(45) |
Nov
(18) |
Dec
(34) |
2010 |
Jan
(12) |
Feb
(28) |
Mar
(18) |
Apr
(19) |
May
(14) |
Jun
(15) |
Jul
(24) |
Aug
(45) |
Sep
(6) |
Oct
(4) |
Nov
(21) |
Dec
(23) |
2011 |
Jan
(24) |
Feb
(45) |
Mar
(56) |
Apr
(18) |
May
(4) |
Jun
(10) |
Jul
(15) |
Aug
(38) |
Sep
(11) |
Oct
(48) |
Nov
(55) |
Dec
(29) |
2012 |
Jan
(41) |
Feb
(15) |
Mar
(24) |
Apr
(17) |
May
(12) |
Jun
(17) |
Jul
(18) |
Aug
(17) |
Sep
(17) |
Oct
(4) |
Nov
(8) |
Dec
(13) |
2013 |
Jan
(9) |
Feb
(1) |
Mar
(10) |
Apr
(18) |
May
(18) |
Jun
(14) |
Jul
(34) |
Aug
(6) |
Sep
(7) |
Oct
|
Nov
(8) |
Dec
(4) |
2014 |
Jan
(12) |
Feb
(6) |
Mar
(1) |
Apr
(12) |
May
|
Jun
(2) |
Jul
(20) |
Aug
(1) |
Sep
|
Oct
(3) |
Nov
(2) |
Dec
|
2015 |
Jan
(16) |
Feb
(2) |
Mar
(9) |
Apr
|
May
(56) |
Jun
(6) |
Jul
(7) |
Aug
(1) |
Sep
(17) |
Oct
(13) |
Nov
(23) |
Dec
(3) |
2016 |
Jan
(10) |
Feb
(8) |
Mar
(34) |
Apr
(19) |
May
(26) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(6) |
Nov
(5) |
Dec
(2) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2019 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
From: Aidas K. <a.k...@gm...> - 2004-04-07 11:40:32
|
Sridhara Jagannath wrote: > hi > I downloaded ipsec-tools-0.3rc5.tar.gz and tried to untar on suse 9.0 > m/c tar -zxvf ipsec-tools-0.3rc5.tar.gz > "I get error gzip:stdin: unexpected end of file ",can anyone help Could you please check if file size is the same as reported on download page (854616). I was not able to download this file from some mirrors. Maybe your download was not completely successful or you catched the moment when mirror you have used was half-way getting this file. The file I've got was uncompressed/untared successfully -- Aidas Kasparas IT administrator GM Consult Group, UAB |
From: Sridhara J. <sja...@no...> - 2004-04-07 11:10:39
|
hi I downloaded ipsec-tools-0.3rc5.tar.gz and tried to untar on suse 9.0 m/c tar -zxvf ipsec-tools-0.3rc5.tar.gz "I get error gzip:stdin: unexpected end of file ",can anyone help regards sridhara.j |
From: Aidas K. <a.k...@gm...> - 2004-04-05 17:20:59
|
Heiko Hund wrote: > On Wednesday 31 March 2004 16:02, Aidas Kasparas wrote: > >>>>It may be acceptable for gateway on small site with dynamic >>>>connectivity. But if I want to [ab]use this functionality on big gw >>>>with some interfaces upped on demand? Therefore I want this to be >>>>made the right way. > > > After some debugging today a couple of questions arouse. > > When looking at socket.c:check_rtsock() I was asking myself if it is really > neccessary to shut down all the sockets in myaddrs (via isakmp_close()) and > if yes, why. I haven't got an answer by now... > Don't know for sure, but think that was the simplest way to implement. As to find out, what exactly we should keep, what to add and what to close is not very simple task. You're welcome to make this the right way too. > Also it appers to me that once an address changed, racoon binds to any > available interfaces, even if a user specified some specific ones in > the .conf. grab_myaddrs() just checks if the address family is right and the > interface is suitable, so any interface matching these criteria will be added > to the lcconf struct. Also the call to find_myaddrs doesn't make much sense > to me, since myaddrs will always be NULL due to the prior call of > isakmp_close(). Am I missing out on something there? Not exactly. Note that if you provide exact address lcconf->autograbaddr is set to 0. This prevents calling check_rtsock() which closes all the sockets and grab_myaddrs(). With all the consequences... > > Since I'll work in this area of racoon to add the iface name feature 'the > right way'(tm) I could also do some fixing/optimization of the code I read. > Take this as a request for permission to fiddle with you code. =) Well, that code is KAME's with some Michal's additions (for NAT-T). Anyway, I think everybody would benefit from better code, so go ahead! -- Aidas Kasparas IT administrator GM Consult Group, UAB |
From: Michal L. <mi...@lo...> - 2004-04-05 16:17:22
|
Hi all, new releases from both 0.2 and 0.3 branches are out. I strongly recommend you to upgrade to either of those, especially if you use X.509 certificates for authentication, because the older versions contain a nasty security bug. Big thanks goes to Ralf Spenneberg for reporting it. In addition you'll get the following improvements in 0.3rc5 release: 0.3rc5 - 05 April 2004 o Security bugfix WRT handling X.509 signatures. o Stability fix WRT unknown PF_KEY messages. o Fixed NAT-T with more proposals (e.g. more crypto algos). o Setkey parses lines one by one => doesn't exit on errors. o Setkey supports readline => more user friendly. As usual, report any problems to: ips...@li... Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: Heiko H. <he...@is...> - 2004-04-03 18:36:51
|
On Wednesday 31 March 2004 16:02, Aidas Kasparas wrote: > >>It may be acceptable for gateway on small site with dynamic > >>connectivity. But if I want to [ab]use this functionality on big gw > >>with some interfaces upped on demand? Therefore I want this to be > >>made the right way. After some debugging today a couple of questions arouse. When looking at socket.c:check_rtsock() I was asking myself if it is really neccessary to shut down all the sockets in myaddrs (via isakmp_close()) and if yes, why. I haven't got an answer by now... Also it appers to me that once an address changed, racoon binds to any available interfaces, even if a user specified some specific ones in the .conf. grab_myaddrs() just checks if the address family is right and the interface is suitable, so any interface matching these criteria will be added to the lcconf struct. Also the call to find_myaddrs doesn't make much sense to me, since myaddrs will always be NULL due to the prior call of isakmp_close(). Am I missing out on something there? Since I'll work in this area of racoon to add the iface name feature 'the right way'(tm) I could also do some fixing/optimization of the code I read. Take this as a request for permission to fiddle with you code. =) Greetings Heiko |
From: Aidas K. <a.k...@gm...> - 2004-03-31 14:02:11
|
>>It may be acceptable for gateway on small site with dynamic >>connectivity. But if I want to [ab]use this functionality on big gw >>with some interfaces upped on demand? Therefore I want this to be >>made the right way. > > > You are right, I haven't spent a thought on multihomed ike gateways. > I'll work it into grab_myaddr and be back again then, or did you have > another place in mind? > Place is right. Just don't forget to update sainfo there too. > >>Speaking of setkey. Have you found the way how to put interface name >>to policy to be stored in SPD? Or just remove need to change setkey-c >>file on every interface change? > I was just curious :-) > > I was thinking of the last scenario. Anything further would probably > lead to a modifiaction of the kernels xfrm structs, which I wanted to > avoid. Thinking of multihomed ike gateways again, the whole thing gets > far more complex, since some spd entries do not need a change and > should not be deleted/reinserted then (I presume setkey does it that > way, not having looked at it). Right now I can't think of anything nice > to deal with this problem in userspace. Any ideas? Sometimes you can find a workaround. If you have policy net-net and add policy gw-net for gateway to be able to speak to internal network, then you can add extra route to that net via internal gateway's interface. Then gateway will connect to remote network from internal address. When I'll manage to finish work on generate-policy, then need for seting policies for dynamic links via setkey will be no longer needed, as racoon will know what policies to set up when link will be established and what to remove when it will go off. -- Aidas Kasparas IT administrator GM Consult Group, UAB |
From: Heiko H. <he...@is...> - 2004-03-31 12:43:53
|
Hi Aidas, > It may be acceptable for gateway on small site with dynamic > connectivity. But if I want to [ab]use this functionality on big gw > with some interfaces upped on demand? Therefore I want this to be > made the right way. You are right, I haven't spent a thought on multihomed ike gateways. I'll work it into grab_myaddr and be back again then, or did you have another place in mind? > Speaking of setkey. Have you found the way how to put interface name > to policy to be stored in SPD? Or just remove need to change setkey-c > file on every interface change? I was thinking of the last scenario. Anything further would probably lead to a modifiaction of the kernels xfrm structs, which I wanted to avoid. Thinking of multihomed ike gateways again, the whole thing gets far more complex, since some spd entries do not need a change and should not be deleted/reinserted then (I presume setkey does it that way, not having looked at it). Right now I can't think of anything nice to deal with this problem in userspace. Any ideas? Greetings Heiko |
From: Aidas K. <a.k...@gm...> - 2004-03-31 11:27:54
|
Hi, Heiko, I understand need for changes like these, I would like to have this functionality included, but I'm not happy with your implementation. The thing that I would like to see changed is the time when you resolve ifname->address. You do this during parsing of configuration file. I would like to see that happen during [re]opening of sockets for listening. Let's see typical scenario. Box has dynamically assigned ip (say, on ppp0), that line drops, redials and is assigned different ip address. During this process racoon gets informed twice of change of interface ip addresses. But, old address of interface is present in configuration directive tree and therefore racoon will not find interface on which to listen. User will need to restart racoon to fix things up. But this will drop all the Phase1 SAs it has negotiated. It may be acceptable for gateway on small site with dynamic connectivity. But if I want to [ab]use this functionality on big gw with some interfaces upped on demand? Therefore I want this to be made the right way. Yes, I understand that struct myaddrs will need to be extended with space for symbolic name of interface. Also some changes will be needed to struct sainfo and it's use. But one allways needs to pay for pleasures... Speaking of setkey. Have you found the way how to put interface name to policy to be stored in SPD? Or just remove need to change setkey-c file on every interface change? Heiko Hund wrote: > Hi, > > I attached a patch to racoon. It enables a user to specify interface > names instead of ip addresses in racoon.conf. This can be quite handy > if you have a ike enabled interface with a dynamically assigned ip > address (e.g. a gateway on a DSL line). > > The sections in racoon.conf concerned are 'listen' and 'sainfo'. With > the patch applied, it's possible to have section like the following in > your racoon.conf file: > > listen > { > isakmp eth0/ipv6 [500]; > isakmp_natt ppp0 [3500]; > } > > sainfo iface ppp0/ipv4/32 any address 1.2.3.4 any > { > ... > } > > racoon will then determine the ip addresses itself, whenever it is > parsing the .conf file. Note that you can specify the address families > ipv4 and ipv6 for a interface like in the examples above. That way it > is possible to have an interface with both type addresses and still > bind to the right socket (or construct the correct id payload in case > of a sainfo section). If you do not specify a address family it > defaults to ipv4. If an interface has more than one address for the > specified family the first one will be assigned and debugging messages > for every other one will be put out to the log. > > I plan to patch setkey so that it will understand ifnames, too. If you > have any objections regarding that or this patch, please let me know. > > Greetings > Heiko -- Aidas Kasparas IT administrator GM Consult Group, UAB |
From: Heiko H. <he...@is...> - 2004-03-31 09:17:29
|
Hi, I attached a patch to racoon. It enables a user to specify interface names instead of ip addresses in racoon.conf. This can be quite handy if you have a ike enabled interface with a dynamically assigned ip address (e.g. a gateway on a DSL line). The sections in racoon.conf concerned are 'listen' and 'sainfo'. With the patch applied, it's possible to have section like the following in your racoon.conf file: listen { isakmp eth0/ipv6 [500]; isakmp_natt ppp0 [3500]; } sainfo iface ppp0/ipv4/32 any address 1.2.3.4 any { ... } racoon will then determine the ip addresses itself, whenever it is parsing the .conf file. Note that you can specify the address families ipv4 and ipv6 for a interface like in the examples above. That way it is possible to have an interface with both type addresses and still bind to the right socket (or construct the correct id payload in case of a sainfo section). If you do not specify a address family it defaults to ipv4. If an interface has more than one address for the specified family the first one will be assigned and debugging messages for every other one will be put out to the log. I plan to patch setkey so that it will understand ifnames, too. If you have any objections regarding that or this patch, please let me know. Greetings Heiko |
From: Marco B. <pu...@ho...> - 2004-03-29 11:25:28
|
Michal Ludvig wrote: > My testbed: > "trillian" with 10.20.0.4 on 'eth0' and 192.168.0.1 on 'lo'. > 2.6.4 running ipsec-tools. > "beeblebrox" with 10.20.0.22 on 'eth0' and 192.168.1.1 on 'lo', > 2.6.4 running freeswan 2.0. >=20 > The goal is to make ESP+IPcomp connection between networks = 192.168.0.0/24 > and 192.168.1.0/24. >=20 > Trillian has a generic racoon.conf and this configuration: > trillian:~ # setkey -c << EOF > spdadd 192.168.1.0/24 192.168.0.0/24 any -P in ipsec > ipcomp/tunnel/10.20.0.22-10.20.0.4/use > esp/transport//require; > spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec > ipcomp/tunnel/10.20.0.4-10.20.0.22/require > esp/transport//require; > EOF > trillian:~ # ip addr add 192.168.0.1/24 dev lo > trillian:~ # ip route add 192.168.1.0/24 via 10.20.0.22 src = 192.168.0.1 Very tricky! Packet from beeblebrox to trillian are going out the tunnel (try running tcpdump). I think that the correct setkey syntax to talk with fsw is: spdadd 192.168.1.0/24 192.168.0.0/24 any -P in ipsec ipcomp/tunnel/10.20.0.22-10.20.0.4/use esp/transport//require; spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec ipcomp/tunnel/10.20.0.4-10.20.0.22/use esp/transport//require; but racoon need to be modified, because it is proposing transport mode and the peer (freeswan pluto) is proposing tunnel. Right? |
From: Michal L. <mi...@lo...> - 2004-03-26 10:28:34
|
On Fri, 26 Mar 2004, James Couzens wrote: > On Thu, 2004-03-25 at 04:31, Michal Ludvig wrote: > > > cryptocard as well? Encryption definitely needs some CPU power and 266 MHz > > processor isn't too much. What encryption do you use? Could you run the > > tunnel with different ciphers to see which one is the fastest? > > Yeah that was with SHA1/3DES (I believe). I'll do some tests in an hour > or so and see how it does with MD5/DES. Also give AES in Phase2 a try. It is said to be fast but I haven't measured it. Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: James C. <jco...@ob...> - 2004-03-26 08:49:47
|
On Thu, 2004-03-25 at 04:31, Michal Ludvig wrote: > Are you running one of those 266MHz boxes? Have you got the HW Yep, the net4801, without an additional crypto card. > cryptocard as well? Encryption definitely needs some CPU power and 266 MH= z > processor isn't too much. What encryption do you use? Could you run the > tunnel with different ciphers to see which one is the fastest? Yeah that was with SHA1/3DES (I believe). I'll do some tests in an hour or so and see how it does with MD5/DES. Cheers, James --=20 James Couzens, Programmer ----------------------------------------------------------------- http://libspf.org -- ANSI C Sender Policy Framework library http://libsrs.org -- ANSI C Sender Rewriting Scheme library ----------------------------------------------------------------- PGP: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xBD3BF855 |
From: Michal L. <mi...@lo...> - 2004-03-25 17:09:38
|
Hi all, because there were some bugreports since 0.3rc3, I decided to make another release candidate. Hopefully the last one. Here is the brief list of changes: 0.3rc4 - 25 March 2004 o Fixed adding "null" encryption via 'setkey'. o Fixed segfault when using AES in Phase1 with OpenSSL>=0.9.7 o Fixed NAT-T in aggresive mode. o Fixed testsuite and added testsuite run into make check. Download here: https://sourceforge.net/project/showfiles.php?group_id=74601&package_id=74949&release_id=226352 Please report any problems to ips...@li... Enjoy! Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: Michal L. <mi...@lo...> - 2004-03-25 12:31:17
|
On Thu, 25 Mar 2004, James Couzens wrote: > File transfers either served from served to the Soekris are pathetically > slow given the bin serving (in this case apache) or the bin getting (in > this case wget) are using all the cycles, slowing the transfer down like > so: > > ### WITHOUT TUNNEL (wget http://10.10.1.2/poop.zip >> /dev/null) > 09:17:37 up 8 days, 5:53, 4 users, load average: 0.16, 0.18, 0.12 > 09:17:29 (2.59 MB/s) - `poop.zip' saved [26243313/26243313] > > ### WITH TUNNEL (wget http://10.10.1.2/poop.zip >> /dev/null) > 09:21:46 up 8 days, 5:57, 4 users, load average: 0.87, 0.52, 0.20 > 09:21:38 (267.83 KB/s) - `poop.zip' saved [26243313/26243313] Are you running one of those 266MHz boxes? Have you got the HW cryptocard as well? Encryption definitely needs some CPU power and 266 MHz processor isn't too much. What encryption do you use? Could you run the tunnel with different ciphers to see which one is the fastest? Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: James C. <jco...@ob...> - 2004-03-25 09:29:41
|
On Thu, 2004-03-18 at 23:23, Michal Ludvig wrote: > If possible gzip the racoon binary and the core file and send it to my > address (not to the list because it will be too big message). >=20 > Michal Ludvig Although the first time I applied the patch and ran racoon, it segfaulted on me as per usual, I out of stubbornness and after back tracing the core, accidentally started racoon again by using the wrong terminal and low an behold it worked... and its been working every time since, so I really dunno. Here is the back trace just for the hell of it: Compiled using GCC 2.95.3 and statically linked against OpenSSL 0.9.7d. Core was generated by `racoon -F -f /etc/racoon/racoon.conf'. Program terminated with signal 11, Segmentation fault. #0 0x4023f68b in ?? () (gdb) bt #0 0x4023f68b in ?? () #1 0x4023f513 in ?? () #2 0x0806c944 in __res_query () #3 0x0806c8c2 in __res_query () #4 0x0806d3bd in __res_query () #5 0x08064bfc in __res_query () #6 0x08067b6b in __res_query () #7 0x08053636 in __res_query () #8 0x0804d089 in __res_query () #9 0x0804c29e in __res_query () #10 0x0804bef7 in __res_query () #11 0x0804b427 in __res_query () #12 0x0804b105 in __res_query () #13 0x401e817d in ?? () http://6o4.ca/racoon03rc3.core.bz2 http://6o4.ca/racoon03rc3.bin.bz2 So, I guess your patch worked like magic. Using 0.3rc3 and no more segfaults on the Soekris! File transfers either served from served to the Soekris are pathetically slow given the bin serving (in this case apache) or the bin getting (in this case wget) are using all the cycles, slowing the transfer down like so: ### WITHOUT TUNNEL (wget http://10.10.1.2/poop.zip >> /dev/null) 09:17:37 up 8 days, 5:53, 4 users, load average: 0.16, 0.18, 0.12 09:17:29 (2.59 MB/s) - `poop.zip' saved [26243313/26243313] ### WITH TUNNEL (wget http://10.10.1.2/poop.zip >> /dev/null) 09:21:46 up 8 days, 5:57, 4 users, load average: 0.87, 0.52, 0.20 09:21:38 (267.83 KB/s) - `poop.zip' saved [26243313/26243313] For reference purposes and to show its really Apache/Wget using a fair bit of of the cycles, here is the same file copied over using SCP: james@code3 james $ scp james@10.10.1.1:/home/httpd/htdocs/openssl-0.9.7d.tar ./ james@10.10.1.1's password:=20 openssl-0.9.7d.tar 100% 25MB 794.8KB/s 00:30=20 I'll try some more tests putting my laptop on one of the additional nics and see what sort of performance difference there is. Any ways, wife is getting pissy and I've got to get to bed =3DD Thanks again Michal (and others for your suggestions), Cheers, James --=20 James Couzens, Programmer ----------------------------------------------------------------- http://libspf.org -- ANSI C Sender Policy Framework library http://libsrs.org -- ANSI C Sender Rewriting Scheme library ----------------------------------------------------------------- PGP: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xBD3BF855 |
From: Michal L. <mi...@lo...> - 2004-03-23 08:25:34
|
Romain Francoise told me that: > I tried out ipsec-tools 0.3rc3 and found out that while AES encryption > works great on a machine with OpenSSL 0.9.6c, it just makes racoon > segfault on one with OpenSSL 0.9.7c. > [...] > Reverting to 3DES makes the tunnel work again. This is on a Debian > unstable system with the 2.6.4 kernel. FWIW, I had no issues whatsoever > with OpenSSL 0.9.7 and my previous version of ipsec-tools (0.2.2). First of all - the correct place to send bugreports is the mailing list, not any of the addresses found in the ChangeLog. Nevertheless thanks for reporting this issue :-) With older IPsec-tools (<= 0.2.x) and/or older OpenSSL < 0.9.7 we didn't use the AES engine proveded by OpenSSL. However with the newest version of both there was apparently a bug in their interoperability. I have fixed it in the CVS and it will also be fixed in the next 0.3 release (either rc4 or final). Appending the patch for your convenience. Everybody: please test the release candidates and report any bugs! Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: James C. <jco...@ob...> - 2004-03-23 04:10:28
|
James Couzens writes: Frederick Grim writes: > Howdy all, > So I am not even sure this is the right mailling list for this but I am > figuring alot of the kernel developers for the > ipsec implementation in the kernel are hanging out here and can at the > least point me toward the right ml. So I am building a > little embedded router based around the wrap 1c board by pc engines. > Since it only has a 266Mhz processor (i586 with mmx) > I want to use a minipci crypto accelerator that is based on the hifn7951 > chipset. There seems to be a driver for the 2.4.x kernel that uses the > Free/SWAN > cryptolib. I am interested in porting this to the current ipsec > implementation. So my question is this: are there hardware crypto hooks > in the current code base? Is this a matter of finding the right struct > and filling in the function pointer with the device specific routines > or is this a much bigger project then that? I read through linux/ipsec.h > and linux/crypto.h and couldn't see anything that looked like > interfaces for hardware accelerators. What code pieces would you guys > recommend reading? I am figuring the free/SWAN > stuff was scrapped in the current kernel so using that as a guide may not > be the best idea. Thanks for the time and feedback > Fred In the event you aren't already talking about the Soekris SBC's the following information might be useful: http://www.soekris.com offers their vpn1401 and vpn1411 (http://soekris.com/Pictures/vpn1401_top.jpg) cards for offloading crypto (the one in the picture uses the hifn7955 chip). You can find experimental Linux drivers for them here: http://sourceforge.net/projects/hifn7951/ There is already FASTIPSEC code available and already in the KAME project. Here is a code reference link you might find useful: http://fxr.watson.org/fxr/source/netipsec/key.c See google or http://www.kame.net/ for more information. Cheers, James --- James Couzens, Programmer ----------------------------------------------------------------- http://libspf.org -- ANSI C Sender Policy Framework library http://libsrs.org -- ANSI C Sender Rewriting Scheme library ----------------------------------------------------------------- |
From: James C. <jco...@6o...> - 2004-03-23 04:06:09
|
Frederick Grim writes: > Howdy all, > So I am not even sure this is the right mailling list for this but I am > figuring alot of the kernel developers for the > ipsec implementation in the kernel are hanging out here and can at the > least point me toward the right ml. So I am building a > little embedded router based around the wrap 1c board by pc engines. > Since it only has a 266Mhz processor (i586 with mmx) > I want to use a minipci crypto accelerator that is based on the hifn7951 > chipset. There seems to be a driver for the 2.4.x kernel that uses the > Free/SWAN > cryptolib. I am interested in porting this to the current ipsec > implementation. So my question is this: are there hardware crypto hooks > in the current code base? Is this a matter of finding the right struct > and filling in the function pointer with the device specific routines > or is this a much bigger project then that? I read through linux/ipsec.h > and linux/crypto.h and couldn't see anything that looked like > interfaces for hardware accelerators. What code pieces would you guys > recommend reading? I am figuring the free/SWAN > stuff was scrapped in the current kernel so using that as a guide may not > be the best idea. Thanks for the time and feedback > Fred In the event you aren't already talking about the Soekris SBC's the following information might be useful: http://www.soekris.com offers their vpn1401 and vpn1411 (http://soekris.com/Pictures/vpn1401_top.jpg) cards for offloading crypto (the one in the picture uses the hifn7955 chip). You can find experimental Linux drivers for them here: http://sourceforge.net/projects/hifn7951/ There is already FASTIPSEC code available and already in the KAME project. Here is a code reference link you might find useful: http://fxr.watson.org/fxr/source/netipsec/key.c See google or http://www.kame.net/ for more information. Cheers, James James Couzens, Programmer ----------------------------------------------------------------- http://libspf.org -- ANSI C Sender Policy Framework library http://libsrs.org -- ANSI C Sender Rewriting Scheme library ----------------------------------------------------------------- |
From: Frederick G. <fg...@no...> - 2004-03-23 00:57:01
|
Howdy all, So I am not even sure this is the right mailling list for this but I am figuring alot of the kernel developers for the ipsec implementation in the kernel are hanging out here and can at the least point me toward the right ml. So I am building a little embedded router based around the wrap 1c board by pc engines. Since it only has a 266Mhz processor (i586 with mmx) I want to use a minipci crypto accelerator that is based on the hifn7951 chipset. There seems to be a driver for the 2.4.x kernel that uses the Free/SWAN cryptolib. I am interested in porting this to the current ipsec implementation. So my question is this: are there hardware crypto hooks in the current code base? Is this a matter of finding the right struct and filling in the function pointer with the device specific routines or is this a much bigger project then that? I read through linux/ipsec.h and linux/crypto.h and couldn't see anything that looked like interfaces for hardware accelerators. What code pieces would you guys recommend reading? I am figuring the free/SWAN stuff was scrapped in the current kernel so using that as a guide may not be the best idea. Thanks for the time and feedback Fred |
From: Brian B. <bbu...@qu...> - 2004-03-22 16:39:47
|
Michal Ludvig wrote: >On Fri, 19 Mar 2004, Brian Buesker wrote: > > > >>Yes, that patch is exactly what I was thinking and had already tried. It >>does fix the problem. Maybe this should be submitted to the linux-net >>mailing list. I'd do it myself, but I have to receive approval before >>doing so, and sometimes that takes a little while. >> >> > >Approval for what? I can submit it if you want. I'll also check if there >is something similar needed for spd_delete. > > I have to get approval before I can submit any patches (unfortunate but true). I think pfkey_spddelete will also need the same change since it uses xfrm_policy_bysel which does a memcmp on the selectors. > > >>Another nice addition to the PF_KEY interface for the SPD would be the >>ability to specify a priority. The Netlink API already allows one to do >>so. The priority just determines where in the SPD the entry is inserted >>(sorted from lowest to highest, with ties determined by order of >>insertion with the newest one last). I'd suggest using the >>sadb_x_policy_reserved2 field of struct sadb_x_policy and then setting >>xp->priority from it in pfkey_spdadd. Does anyone know if there is any >>reason this field cannot be used for the priority? >> >> > >How about SADB_X_SPDSETIDX? Shouldn't it do something similar? > > Hmm, that's interesting. I hadn't seen that before. Right now it just uses pfkey_spdadd so it doesn't do anything different. It defintely could be made to do something different though. I guess it could even be extended to allow specifying an interface index as well (as the xfrm_user API supports). Maybe that would be the better way to go. There could be an additional header which holds the priority and interface index, and the kernel could fall back to using just the normal pfkey_spdadd if that header isn't present. Brian >Michal Ludvig > > |
From: Brian B. <bbu...@qu...> - 2004-03-22 16:27:24
|
Aidas Kasparas wrote: > Hi, > > I think these two are separate problems and we would have better > chances if we don't mix solutions for both of them to one patch sent > to linux-net. Agreed. > > Re: family. Does anybody know design reason why there are two > "family" fields: in selector and in policy? Is there some docs HOW > these two should be set? If not - I would propose to post this > question to linux-net and only after that suggest solution. I really don't know why there are two "family" fields. It seems that the family field inside struct xfrm_selector is only used when checking for duplicated policies, while the family field in struct xfrm_policy is used for lookup operations. It probably would be a good thing to ask on linux-net. > > Re: priority - I understand the need for it, I understand that > pf_key interface will need to be extended. The only questions I have > are how does proposed method fit RFC-2367? What will happen if one of > ipsec-tools or kernel will not support new method? IIRC, RFC 2367 doesn't specify PF_KEY for SPD policies. I think it only specifies the interface to the SADB. So I don't think we would be violating it. If we went with the approach to use the sadb_x_policy_reserved2 field then if ipsec-tools didn't support it but the kernel did, it would still get inserted at the end of the SPD list since the kernel would always receive policies with a priority of 0. If the kernel did not support it but ipsec-tools did, then the old behavior would again just occur since the kernel would just be defaulting the priority to 0 as it does right now. Brian > > Brian Buesker wrote: > >> Yes, that patch is exactly what I was thinking and had already tried. >> It does fix the problem. Maybe this should be submitted to the >> linux-net mailing list. I'd do it myself, but I have to receive >> approval before doing so, and sometimes that takes a little while. >> >> Another nice addition to the PF_KEY interface for the SPD would be >> the ability to specify a priority. The Netlink API already allows one >> to do so. The priority just determines where in the SPD the entry is >> inserted (sorted from lowest to highest, with ties determined by >> order of insertion with the newest one last). I'd suggest using the >> sadb_x_policy_reserved2 field of struct sadb_x_policy and then >> setting xp->priority from it in pfkey_spdadd. Does anyone know if >> there is any reason this field cannot be used for the priority? >> >> If the kernel modification was made, then setkey could be extended to >> allow the priority to be specified, and support for the priority >> could be added to racoon and libipsec. I started doing this but got >> sidetracked with other tasks and I don't know exactly when I'll be >> able to come back to it. Thoughts on this suggestion? >> >> Brian >> >> Michal Ludvig wrote: >> >>> On Mon, 15 Mar 2004, Brian Buesker wrote: >>> >>> >>> >>>> I came across the following problem. If you want to have a policy that >>>> will match any IPv4 and IPv6 address for a specific port, say 21, >>>> it is >>>> not possible to insert a single policy to do this nor is it >>>> possible to >>>> insert two different policies. For example, if you just do: >>>> >>>> spdadd ::0/0[any] ::0/0[21] tcp -P in ipsec esp/transport//require; >>>> spdadd ::0/0[21] ::0/0[any] tcp -P out ipsec esp/transport//require; >>>> >>>> Then these policies are only matched for IPv6 addresses, since >>>> xfrm_policy_lookup compares the family of the policy to the family of >>>> the flow. >>>> >>>> If instead you try to insert a policy for both IPv4 and IPv6, such as: >>>> >>>> spdadd ::0/0[any] ::0/0[5000] tcp -P in ipsec esp/transport//require; >>>> spdadd ::0/0[5000] ::0/0[any] tcp -P out ipsec esp/transport//require; >>>> >>>> spdadd 0.0.0.0/0[any] 0.0.0.0/0[21] tcp -P in ipsec >>>> esp/transport//require; >>>> spdadd 0.0.0.0/0[21] 0.0.0.0/0[any] tcp -P out ipsec >>>> esp/transport//require; >>>> >>>> Then you get an error saying the policy already exists, since >>>> xfrm_policy_insert just compares the selectors and the family for them >>>> doesn't get set by the PF_KEY code. I think the Netlink interface does >>>> set the family in the selector, so it would allow for both IPv4 and >>>> IPv6 policies to be inserted. Maybe PF_KEY should do this as well, by >>>> setting xp->selector.family = xp->family in pfkey_spdadd. >>>> >>> >>> >>> >>> Something like the attached? Not tested, but looks reasonable... >>> >>> Michal Ludvig >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> --- linux-2.6.3.patched/net/key/af_key.c 2004-03-05 >>> 14:22:22.000000000 +0100 >>> +++ linux-2.6.3/net/key/af_key.c 2004-03-19 18:06:59.000000000 +0100 >>> @@ -1863,6 +1863,7 @@ static int pfkey_spdadd(struct sock *sk, >>> err = -EINVAL; >>> goto out; >>> } >>> + xp->selector.family - xp->family; >>> xp->selector.prefixlen_s = sa->sadb_address_prefixlen; >>> xp->selector.proto = pfkey_proto_to_xfrm(sa->sadb_address_proto); >>> xp->selector.sport = ((struct sockaddr_in *)(sa+1))->sin_port; >>> >>> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> Ipsec-tools-devel mailing list >> Ips...@li... >> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel > > |
From: Michal L. <mi...@lo...> - 2004-03-22 10:04:27
|
On Fri, 19 Mar 2004, Brian Buesker wrote: > Yes, that patch is exactly what I was thinking and had already tried. It > does fix the problem. Maybe this should be submitted to the linux-net > mailing list. I'd do it myself, but I have to receive approval before > doing so, and sometimes that takes a little while. Approval for what? I can submit it if you want. I'll also check if there is something similar needed for spd_delete. > Another nice addition to the PF_KEY interface for the SPD would be the > ability to specify a priority. The Netlink API already allows one to do > so. The priority just determines where in the SPD the entry is inserted > (sorted from lowest to highest, with ties determined by order of > insertion with the newest one last). I'd suggest using the > sadb_x_policy_reserved2 field of struct sadb_x_policy and then setting > xp->priority from it in pfkey_spdadd. Does anyone know if there is any > reason this field cannot be used for the priority? How about SADB_X_SPDSETIDX? Shouldn't it do something similar? Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: Aidas K. <a.k...@gm...> - 2004-03-21 10:16:38
|
Hi, I think these two are separate problems and we would have better chances if we don't mix solutions for both of them to one patch sent to linux-net. Re: family. Does anybody know design reason why there are two "family" fields: in selector and in policy? Is there some docs HOW these two should be set? If not - I would propose to post this question to linux-net and only after that suggest solution. Re: priority - I understand the need for it, I understand that pf_key interface will need to be extended. The only questions I have are how does proposed method fit RFC-2367? What will happen if one of ipsec-tools or kernel will not support new method? Brian Buesker wrote: > Yes, that patch is exactly what I was thinking and had already tried. It > does fix the problem. Maybe this should be submitted to the linux-net > mailing list. I'd do it myself, but I have to receive approval before > doing so, and sometimes that takes a little while. > > Another nice addition to the PF_KEY interface for the SPD would be the > ability to specify a priority. The Netlink API already allows one to do > so. The priority just determines where in the SPD the entry is inserted > (sorted from lowest to highest, with ties determined by order of > insertion with the newest one last). I'd suggest using the > sadb_x_policy_reserved2 field of struct sadb_x_policy and then setting > xp->priority from it in pfkey_spdadd. Does anyone know if there is any > reason this field cannot be used for the priority? > > If the kernel modification was made, then setkey could be extended to > allow the priority to be specified, and support for the priority could > be added to racoon and libipsec. I started doing this but got > sidetracked with other tasks and I don't know exactly when I'll be able > to come back to it. Thoughts on this suggestion? > > Brian > > Michal Ludvig wrote: > >> On Mon, 15 Mar 2004, Brian Buesker wrote: >> >> >> >>> I came across the following problem. If you want to have a policy that >>> will match any IPv4 and IPv6 address for a specific port, say 21, it is >>> not possible to insert a single policy to do this nor is it possible to >>> insert two different policies. For example, if you just do: >>> >>> spdadd ::0/0[any] ::0/0[21] tcp -P in ipsec esp/transport//require; >>> spdadd ::0/0[21] ::0/0[any] tcp -P out ipsec esp/transport//require; >>> >>> Then these policies are only matched for IPv6 addresses, since >>> xfrm_policy_lookup compares the family of the policy to the family of >>> the flow. >>> >>> If instead you try to insert a policy for both IPv4 and IPv6, such as: >>> >>> spdadd ::0/0[any] ::0/0[5000] tcp -P in ipsec esp/transport//require; >>> spdadd ::0/0[5000] ::0/0[any] tcp -P out ipsec esp/transport//require; >>> >>> spdadd 0.0.0.0/0[any] 0.0.0.0/0[21] tcp -P in ipsec >>> esp/transport//require; >>> spdadd 0.0.0.0/0[21] 0.0.0.0/0[any] tcp -P out ipsec >>> esp/transport//require; >>> >>> Then you get an error saying the policy already exists, since >>> xfrm_policy_insert just compares the selectors and the family for them >>> doesn't get set by the PF_KEY code. I think the Netlink interface does >>> set the family in the selector, so it would allow for both IPv4 and >>> IPv6 policies to be inserted. Maybe PF_KEY should do this as well, by >>> setting xp->selector.family = xp->family in pfkey_spdadd. >>> >> >> >> Something like the attached? Not tested, but looks reasonable... >> >> Michal Ludvig >> >> >> ------------------------------------------------------------------------ >> >> --- linux-2.6.3.patched/net/key/af_key.c 2004-03-05 >> 14:22:22.000000000 +0100 >> +++ linux-2.6.3/net/key/af_key.c 2004-03-19 18:06:59.000000000 +0100 >> @@ -1863,6 +1863,7 @@ static int pfkey_spdadd(struct sock *sk, >> err = -EINVAL; >> goto out; >> } >> + xp->selector.family - xp->family; >> xp->selector.prefixlen_s = sa->sadb_address_prefixlen; >> xp->selector.proto = pfkey_proto_to_xfrm(sa->sadb_address_proto); >> xp->selector.sport = ((struct sockaddr_in *)(sa+1))->sin_port; >> >> > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel -- Aidas Kasparas IT administrator GM Consult Group, UAB |
From: Michal L. <mi...@lo...> - 2004-03-19 17:42:42
|
On Fri, 19 Mar 2004, [iso-8859-1] M?ns Rullg?rd wrote: > Michal Ludvig <mi...@lo...> writes: > > > --- linux-2.6.3.patched/net/key/af_key.c 2004-03-05 14:22:22.000000000 +0100 > > +++ linux-2.6.3/net/key/af_key.c 2004-03-19 18:06:59.000000000 +0100 > > @@ -1863,6 +1863,7 @@ static int pfkey_spdadd(struct sock *sk, > > err = -EINVAL; > > goto out; > > } > > + xp->selector.family - xp->family; > > That statement does nothing, AFAICS. Oops, should have been: xp->selector.family = xp->family; Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: Brian B. <bbu...@qu...> - 2004-03-19 17:41:57
|
Yes, that patch is exactly what I was thinking and had already tried. It does fix the problem. Maybe this should be submitted to the linux-net mailing list. I'd do it myself, but I have to receive approval before doing so, and sometimes that takes a little while. Another nice addition to the PF_KEY interface for the SPD would be the ability to specify a priority. The Netlink API already allows one to do so. The priority just determines where in the SPD the entry is inserted (sorted from lowest to highest, with ties determined by order of insertion with the newest one last). I'd suggest using the sadb_x_policy_reserved2 field of struct sadb_x_policy and then setting xp->priority from it in pfkey_spdadd. Does anyone know if there is any reason this field cannot be used for the priority? If the kernel modification was made, then setkey could be extended to allow the priority to be specified, and support for the priority could be added to racoon and libipsec. I started doing this but got sidetracked with other tasks and I don't know exactly when I'll be able to come back to it. Thoughts on this suggestion? Brian Michal Ludvig wrote: >On Mon, 15 Mar 2004, Brian Buesker wrote: > > > >>I came across the following problem. If you want to have a policy that >>will match any IPv4 and IPv6 address for a specific port, say 21, it is >>not possible to insert a single policy to do this nor is it possible to >>insert two different policies. For example, if you just do: >> >>spdadd ::0/0[any] ::0/0[21] tcp -P in ipsec esp/transport//require; >>spdadd ::0/0[21] ::0/0[any] tcp -P out ipsec esp/transport//require; >> >>Then these policies are only matched for IPv6 addresses, since >>xfrm_policy_lookup compares the family of the policy to the family of >>the flow. >> >>If instead you try to insert a policy for both IPv4 and IPv6, such as: >> >>spdadd ::0/0[any] ::0/0[5000] tcp -P in ipsec esp/transport//require; >>spdadd ::0/0[5000] ::0/0[any] tcp -P out ipsec esp/transport//require; >> >>spdadd 0.0.0.0/0[any] 0.0.0.0/0[21] tcp -P in ipsec esp/transport//require; >>spdadd 0.0.0.0/0[21] 0.0.0.0/0[any] tcp -P out ipsec esp/transport//require; >> >>Then you get an error saying the policy already exists, since >>xfrm_policy_insert just compares the selectors and the family for them >>doesn't get set by the PF_KEY code. I think the Netlink interface does >>set the family in the selector, so it would allow for both IPv4 and >>IPv6 policies to be inserted. Maybe PF_KEY should do this as well, by >>setting xp->selector.family = xp->family in pfkey_spdadd. >> >> > >Something like the attached? Not tested, but looks reasonable... > >Michal Ludvig > > >------------------------------------------------------------------------ > >--- linux-2.6.3.patched/net/key/af_key.c 2004-03-05 14:22:22.000000000 +0100 >+++ linux-2.6.3/net/key/af_key.c 2004-03-19 18:06:59.000000000 +0100 >@@ -1863,6 +1863,7 @@ static int pfkey_spdadd(struct sock *sk, > err = -EINVAL; > goto out; > } >+ xp->selector.family - xp->family; > xp->selector.prefixlen_s = sa->sadb_address_prefixlen; > xp->selector.proto = pfkey_proto_to_xfrm(sa->sadb_address_proto); > xp->selector.sport = ((struct sockaddr_in *)(sa+1))->sin_port; > > |