From: Andreas N. <Andreas.Nobel@FernUni-Hagen.de> - 2005-04-27 14:35:58
|
Is any of the devs willing to write IPComp handeling on the todo list? This is the expirance that i have make so far: In the remote section for the phase2 we are forced to have a line with compression algorithm otherwise a racoon.conf parse error will occur. sainfo anonymous { pfs_group 5; lifetime time 3 min; encryption_algorithm aes256, 3des, blowfish 448; authentication_algorithm hmac_sha1; compression_algorithm lzs, deflate; If i define that line there are still on IPSec SA created who have are containing IPComp (data gets compressed before encryption to be smaller sited traveling over the network link). But why is this compression_algorithm lzs, deflate; needed then, if it doesn't make the job as i would expect? According to Manu is would be a bug on racoon.conf parser. I have looked up how a polices which meets this requirements have to look like (i have tested it withn setkey command and setkey -DP as result). Result from setkey -DP output: A.B.C.D[any] 0.0.0.0/0[any] any in prio def ipsec ipcomp/tunnel/A.B.C.D-84.144.56.4/require esp/tunnel/A.B.C.D-84.144.56.4/require created: Apr 26 17:39:25 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=3512 seq=10 pid=6889 refcnt=1 0.0.0.0/0[any] A.B.C.D[any] any out prio def ipsec ipcomp/tunnel/84.144.56.-A.B.C.D/require esp/tunnel/84.144.56.4-A.B.C.D/require created: Apr 26 17:39:25 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=3529 seq=8 pid=6889 refcnt=1 A.B.C.D[any] 0.0.0.0/0[any] any fwd prio def ipsec ipcomp/tunnel/A.B.C.D-84.144.56.4/require esp/tunnel/A.B.C.D-84.144.56.4/require created: Apr 26 17:39:25 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=3522 seq=6 pid=6889 refcnt=1 Policies manually created using setkey.conf spdadd A.B.C.D/32 0.0.0.0/0 any -P in ipsec ipcomp/tunnel/A.B.C.D-84.144.56.4/require esp/tunnel/A.B.C.D-84.144.56.4/require; spdadd 0.0.0.0/0 A.B.C.D/32 any -P out ipsec ipcomp/tunnel/84.144.56.4-A.B.C.D/require esp/tunnel/84.144.56.4-A.B.C.D/require; What i want is to say when using the compression_algorithm lzs, deflate; directive in racoon.conf and also doing generate policy_on; that the phase 2 IPSec SA's are setup with IPComp AND ESP Proposals as i did manually with setkey.conf so that we can make use of IPComp (compression factor up to 3x for the data send trough the Tunnel. This leads out in saving network traffic when running racoon as a server where roadwarriors are initating connections from their VPN Clients to the VPN Gateway. IPComp can make use of deflate or much better and the thing to go for IPSec VPN Clients using LZS Lempel-Ziv Standard Compression. The compression algorithm are also flexible (exchangeable) as the enycryption / authentification algorithms on ISAKMP phase1 / 2. And maybe (i don't know how much work iit is) making the compression_algorithm directive optional for the phase 2 proposal config block in racoon.conf for the users that are using generate_policy on; but don't want any IPComp compression. This shouldn't affect others scenarios (with fixed IPs --> no roadwarrior connections). Can you have a look to this issue? That would be nice to have this feature working as expected. I think it would require IPComp kernel support and compression algorithm installed on the box. A switch where we can specify if we want to make use of IPComp for IPSEC SA like: ipcomp on/off; and the already existing compression_algorithm lzs, deflate; for choosing the way how the data will be compressed before it is getting encrypted. Cheers, Andreas |
From: Andreas N. <Andreas.Nobel@FernUni-Hagen.de> - 2005-05-07 17:01:06
|
I have tested using a different VPN Client Software as Roadwarrior / Tunnel Initator with IPComp+ESP Proposal. So the Client ask specially for IPComp Proposal! When choosing IPComp on the Client side no IPSec traffic will flow trough the tunnel! Deactivating fixes this problem immediately. So there is a bug on IPComp and ipsec-tools. During the time i have enabled IPComp LZS compression on the client side generate on IPSec SAs are set up and setkey -DP give me same same result of SPD as no IPComp would be specified. Here are the RFC i have found out in addition: http://www.faqs.org/rfcs/rfc3051.html And the most common compression algorithm for IPSec tunnel is LZS. IP Payload Compression Using LZS", RFC 2395: http://www.faqs.org/rfcs/rfc2395.html This compression algorithm is used by ALL good vendors of VPN Clients and central site gateways / appliancies. Maybe this helps to locate the problem. Andreas |
From: Andreas N. <Andreas.Nobel@FernUni-Hagen.de> - 2005-04-29 11:51:33
|
So far here is the result i got: IPComp with 2.6 native IPsec is insecure when done with ipsec-tools. Racoon puts an extraneous IPIP header into IPComp packets, which defeats the purpose of the compression and constitutes a security risk. IPComp should work ok with 2.6.5+ kernels... At best, putting a second IPIP header in between ESP and IPcomp is a simple waste of 20 bytes. At worst, the code that permits such a packet to be received and processed may in fact permit IP source address spoofing *inside* of the tunnel... According to the latest IPComp RFC (RFC2393 defines IPcomp, later updated by RFC3173), both kame native implementation and ipsec-tools port has the same issue. 2.6 Kernel side is definately okay. This is what racoon does: IPa TCP data This packet then becomes the *PAYLOAD* of the ESP-tunnel mode: IPb ESP IPa TCP data By the first paragraph, the IPcomp does not go get inserted as: IPb IPcomp ESP IPa TCP data because you can't compress encrypted data, which is actually the whole reason for IPcomp. ESP screws up any compression that PPP was getting. You have to insert it afterwards, which results in: IPb ESP IPcomp IPa TCP data At no point does the RFC says ANYTHING about inserting a second IP-IP header into the packet so this leads out that racoon doesn't follow the RFC to the letter. Racoon does only interoperate with itself because both ends uses the same "error prone" and security issued ipcomp implementation. Because of this there is still no chance to interoperate with other vendor appliancies / gateways / vpn clients ncp / cisco etc. which use ipcomp static lzs . Any change to get this security issue / bug solved? Cheers, Andreas |
From: Aidas K. <a.k...@gm...> - 2005-04-29 13:15:55
|
Have you tried to: 1) change positions of ipcomp and esp in setkey directive; 2) use transport mode for ipcomp. Andreas Nobel wrote: > So far here is the result i got: > > IPComp with 2.6 native IPsec is insecure when done with ipsec-tools. > Racoon puts an extraneous IPIP header into IPComp packets, which defeats > the purpose of the compression and constitutes a security risk. > > IPComp should work ok with 2.6.5+ kernels... > > At best, putting a second IPIP header in between ESP and IPcomp is a > simple waste of 20 bytes. > At worst, the code that permits such a packet to be received and > processed may in fact permit IP source address spoofing *inside* of the > tunnel... > > According to the latest IPComp RFC (RFC2393 defines IPcomp, later > updated by RFC3173), both kame native implementation and ipsec-tools > port has the same issue. 2.6 Kernel side is definately okay. > > This is what racoon does: > > IPa TCP data > > This packet then becomes the *PAYLOAD* of the ESP-tunnel mode: > > IPb ESP IPa TCP data > > By the first paragraph, the IPcomp does not go get inserted as: > IPb IPcomp ESP IPa TCP data > > because you can't compress encrypted data, which is actually the whole > reason for IPcomp. ESP screws up any compression that PPP was getting. > You have to insert it afterwards, which results in: > > IPb ESP IPcomp IPa TCP data > > At no point does the RFC says ANYTHING about inserting a second IP-IP > header into the packet so this leads out that racoon doesn't follow the > RFC to the letter. > > Racoon does only interoperate with itself because both ends uses the > same "error prone" and security issued ipcomp implementation. > > Because of this there is still no chance to interoperate with other > vendor appliancies / gateways / vpn clients ncp / cisco etc. which use > ipcomp static lzs . > > > Any change to get this security issue / bug solved? > > > Cheers, > > Andreas > > > ------------------------------------------------------- > SF.Net email is sponsored by: Tell us your software development plans! > Take this survey and enter to win a one-year sub to SourceForge.net > Plus IDC's 2005 look-ahead and a copy of this survey > Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix > _______________________________________________ > 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: Marco B. <pu...@ho...> - 2005-04-29 14:10:01
|
Hi Aidas and Andreas. This is a pretty old issue (december 2003). http://www.mail-archive.com/fre...@fr.../msg10983.html This problem hasn't been resolved. This affect all kame based configuration tools (setkey). ----- Original Message ----- From: "Aidas Kasparas" <a.k...@gm...> To: "Andreas Nobel" <Andreas.Nobel@FernUni-Hagen.de> Cc: <ips...@li...> Sent: Friday, April 29, 2005 3:15 PM Subject: Re: [Ipsec-tools-devel] IPComp Implementation for generate on IPSec SAs > Have you tried to: > 1) change positions of ipcomp and esp in setkey directive; > 2) use transport mode for ipcomp. > > Andreas Nobel wrote: > > So far here is the result i got: > > > > IPComp with 2.6 native IPsec is insecure when done with ipsec-tools. > > Racoon puts an extraneous IPIP header into IPComp packets, which defeats > > the purpose of the compression and constitutes a security risk. > > > > IPComp should work ok with 2.6.5+ kernels... > > > > At best, putting a second IPIP header in between ESP and IPcomp is a > > simple waste of 20 bytes. > > At worst, the code that permits such a packet to be received and > > processed may in fact permit IP source address spoofing *inside* of the > > tunnel... > > > > According to the latest IPComp RFC (RFC2393 defines IPcomp, later > > updated by RFC3173), both kame native implementation and ipsec-tools > > port has the same issue. 2.6 Kernel side is definately okay. > > > > This is what racoon does: > > > > IPa TCP data > > > > This packet then becomes the *PAYLOAD* of the ESP-tunnel mode: > > > > IPb ESP IPa TCP data > > > > By the first paragraph, the IPcomp does not go get inserted as: > > IPb IPcomp ESP IPa TCP data > > > > because you can't compress encrypted data, which is actually the whole > > reason for IPcomp. ESP screws up any compression that PPP was getting. > > You have to insert it afterwards, which results in: > > > > IPb ESP IPcomp IPa TCP data > > > > At no point does the RFC says ANYTHING about inserting a second IP-IP > > header into the packet so this leads out that racoon doesn't follow the > > RFC to the letter. > > > > Racoon does only interoperate with itself because both ends uses the > > same "error prone" and security issued ipcomp implementation. > > > > Because of this there is still no chance to interoperate with other > > vendor appliancies / gateways / vpn clients ncp / cisco etc. which use > > ipcomp static lzs . > > > > > > Any change to get this security issue / bug solved? > > > > > > Cheers, > > > > Andreas > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: Tell us your software development plans! > > Take this survey and enter to win a one-year sub to SourceForge.net > > Plus IDC's 2005 look-ahead and a copy of this survey > > Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix > > _______________________________________________ > > Ipsec-tools-devel mailing list > > Ips...@li... > > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel > > -- > Aidas Kasparas > IT administrator > GM Consult Group, UAB > > > ------------------------------------------------------- > SF.Net email is sponsored by: Tell us your software development plans! > Take this survey and enter to win a one-year sub to SourceForge.net > Plus IDC's 2005 look-ahead and a copy of this survey > Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel > |
From: Andreas N. <Andreas.Nobel@FernUni-Hagen.de> - 2005-04-29 14:32:25
|
>This is a pretty old issue (december 2003). >http://www.mail-archive.com/fre...@fr.../msg10983.html > >This problem hasn't been resolved. This affect all kame >based >configuration >tools (setkey). Hi Marco, thanks for the URl. Yes, i see. Is there anyone else who has problems using IPComp with other IPSec sites / appliances / clients when Racoon is used? >----- Original Message ----- >From: "Aidas Kasparas" <a.k...@gm...> >To: "Andreas Nobel" <Andreas.Nobel@FernUni-Hagen.de> >Cc: <ips...@li...> >Sent: Friday, April 29, 2005 3:15 PM >Subject: Re: [Ipsec-tools-devel] IPComp Implementation >for generate on >IPSec SAs > > >> Have you tried to: >> 1) change positions of ipcomp and esp in setkey >>directive; >> 2) use transport mode for ipcomp. Racoon only does the IPComp job when used with "insecurer" and NAT-T problem causer in Transport Mode. spdadd A.B.C.D/32 0.0.0.0/0 any -P in ipsec ipcomp/tunnel/A.B.C.D-84.144.56.4/require esp/tunnel/A.B.C.D-84.144.56.4/require; This must work also when using IPComp+ESP as IPSec SA Proposals for Remote ends. Transport mode is only used when doing End to End connections while Tunnel mode is used for the most common setups and protect the inner IP addresses (Virtual IPs) of the communication partners. So believe me this is a real bug :) |
From: Marco B. <pu...@ho...> - 2005-04-29 15:09:22
|
Andreas Nobel wrote: > spdadd A.B.C.D/32 0.0.0.0/0 any -P in ipsec > ipcomp/tunnel/A.B.C.D-84.144.56.4/require ^^^^^^^ Just for record. You should change "require" to "use" because small packets could become bigger after compression. |
From: Andreas N. <Andreas.Nobel@FernUni-Hagen.de> - 2005-04-29 15:57:32
|
>Just for record. >You should change "require" to "use" because >small packets could become bigger after >compression. Thanks for pointing this out. Does your setup (which one?) work with ESP+IPComp NAT-T AND Tunnel Mode? I want to use IPComp+ESP in Tunnel Mode with generate on; created IPSec SAs for Racoon on the server side and its roadwarriors. and maybe a switch for choosing ipcomp on/off; on racoon.conf for those how don't neeed IPComp, so manually setting up SAD/SPD is no chice for me. Andreas |
From: Marco B. <pu...@ho...> - 2005-05-02 07:35:11
|
Andreas Nobel wrote: > >Just for record. > >You should change "require" to "use" because > >small packets could become bigger after > >compression. > > Thanks for pointing this out. > > Does your setup (which one?) work with ESP+IPComp NAT-T > AND Tunnel Mode? This is my interop list: FreeS/WAN (KLIPS + linux 2.4) - FreeS/WAN (2.6 Ipsec) = ESP+IPCOMP OK FreeS/WAN (KLIPS + linux 2.4) - FreeS/WAN (2.6 Ipsec) = ESP OK FreeS/WAN (KLIPS + linux 2.4) - racoon/setkey (2.6 Ipsec) = ESP OK FreeS/WAN (KLIPS + linux 2.4) - racoon/setkey (2.6 Ipsec) = ESP+IPCOMP KO I haven't tested NAT-T. > I want to use IPComp+ESP in Tunnel Mode with generate on; > created IPSec SAs for Racoon on the server side and its > roadwarriors. and maybe a switch for choosing ipcomp > on/off; on racoon.conf for those how don't neeed IPComp, > so manually setting up SAD/SPD is no chice for me. > > > Andreas |
From: VANHULLEBUS Y. <va...@fr...> - 2005-04-29 15:25:43
|
On Fri, Apr 29, 2005 at 05:09:15PM +0200, Marco Berizzi wrote: > Andreas Nobel wrote: > > > spdadd A.B.C.D/32 0.0.0.0/0 any -P in ipsec > > ipcomp/tunnel/A.B.C.D-84.144.56.4/require > ^^^^^^^ > Just for record. > You should change "require" to "use" because > small packets could become bigger after > compression. Except if there is any specific code for IPComp, "use" means "do the action if an SA is available". So this won't change anything for small packets. Yvan. |
From: Ganesan R. <rga...@us...> - 2005-04-30 08:39:19
|
>>>>> "VANHULLEBUS" == VANHULLEBUS Yvan <va...@fr...> writes: > On Fri, Apr 29, 2005 at 05:09:15PM +0200, Marco Berizzi wrote: >> Andreas Nobel wrote: >> >> > spdadd A.B.C.D/32 0.0.0.0/0 any -P in ipsec >> > ipcomp/tunnel/A.B.C.D-84.144.56.4/require >> ^^^^^^^ >> Just for record. >> You should change "require" to "use" because >> small packets could become bigger after >> compression. > Except if there is any specific code for IPComp, "use" means "do the > action if an SA is available". > So this won't change anything for small packets. It matters in the Linux kernel. If the packet is too small to compress, kernel tries to send it without encryption. Because the kernel interprets "require" too strictly, the packet gets dropped. This is a Linux kernel bug, compression is not same as encryption. I don't know if any one has reported it yet. -- Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA Web: http://employees.org/~rganesan | http://rganesan.blogspot.com |
From: Aidas K. <a.k...@gm...> - 2005-04-29 15:24:22
|
Marco, Maybe it is old issue because nobody tried hard enought to solve it. The reason why I had suggestions I provided in my earlier post are: 1) setkey allows you to construct whatever policy you ask it to. It allowed to enter policy like Andreas supplied, but it gives no guarantees that such policy is reasonable. If kernel constructs headers in wrong order, then it is because user asked it to act this way! Therefore I asked to try to change order. From which end of policy string construction of headers starts I don't know. But it is possible that it is done in non-intuitive way (please find out). 2) Packets are constructed by kernel, not by setkey or racoon. Therefore, if extra headers are added, then either a) administrator has asked for wrong policy, or b) setkey has put policy into kernel which is different from the one supplied by user, or c) there is a bug in the kernel, or d) there is [yet] no way how to express via pfkey interface what you want! Look, when you say that policy is whatever/TUNNEL/start-end/whatever, you ask to leave original addresses inside and put tunnel start and end addresses as source and destination of outer header. When you put two tunnel descriptions, where neither ipsec nor esp has space for ip addresses, then there is the only way to fullfill this requirement -- add ipip header. If you don't want that ipip header, then you have to use somewhere TRANSPORT. Let's try to construct packet you want. First, you want original ip header inside ipcomp header. Therefore you have to use TUNNEL. After this transformation you'll get packets with outer headers directing them from your gateway to peer's gateway. You don't need to change addresses anymore. Therefore for esp you can and have to use TRANSPORT! Given what Andreas policies constructed headers in wrong order, I suspect that correct policy would be: spdadd <from> <to> any -P out esp/transport//require ipcomp/tunnel/84.144.56.4-A.B.C.D/require; Ok, not exactly what I suggested in previous post, but in the same direction. Please try it. Marco Berizzi wrote: > Hi Aidas and Andreas. > > This is a pretty old issue (december 2003). > http://www.mail-archive.com/fre...@fr.../msg10983.html > > This problem hasn't been resolved. This affect all kame based > configuration > tools (setkey). > > ----- Original Message ----- > From: "Aidas Kasparas" <a.k...@gm...> > To: "Andreas Nobel" <Andreas.Nobel@FernUni-Hagen.de> > Cc: <ips...@li...> > Sent: Friday, April 29, 2005 3:15 PM > Subject: Re: [Ipsec-tools-devel] IPComp Implementation for generate on > IPSec SAs > > > >>Have you tried to: >>1) change positions of ipcomp and esp in setkey directive; >>2) use transport mode for ipcomp. >> >>Andreas Nobel wrote: >> >>>So far here is the result i got: >>> >>>IPComp with 2.6 native IPsec is insecure when done with ipsec-tools. >>>Racoon puts an extraneous IPIP header into IPComp packets, which > > defeats > >>>the purpose of the compression and constitutes a security risk. >>> >>>IPComp should work ok with 2.6.5+ kernels... >>> >>>At best, putting a second IPIP header in between ESP and IPcomp is a >>>simple waste of 20 bytes. >>>At worst, the code that permits such a packet to be received and >>>processed may in fact permit IP source address spoofing *inside* of > > the > >>>tunnel... >>> >>>According to the latest IPComp RFC (RFC2393 defines IPcomp, later >>>updated by RFC3173), both kame native implementation and ipsec-tools >>>port has the same issue. 2.6 Kernel side is definately okay. >>> >>>This is what racoon does: >>> >>> IPa TCP data >>> >>>This packet then becomes the *PAYLOAD* of the ESP-tunnel mode: >>> >>> IPb ESP IPa TCP data >>> >>>By the first paragraph, the IPcomp does not go get inserted as: >>> IPb IPcomp ESP IPa TCP data >>> >>>because you can't compress encrypted data, which is actually the > > whole > >>>reason for IPcomp. ESP screws up any compression that PPP was > > getting. > >>>You have to insert it afterwards, which results in: >>> >>> IPb ESP IPcomp IPa TCP data >>> >>>At no point does the RFC says ANYTHING about inserting a second > > IP-IP > >>>header into the packet so this leads out that racoon doesn't follow > > the > >>>RFC to the letter. >>> >>>Racoon does only interoperate with itself because both ends uses the >>>same "error prone" and security issued ipcomp implementation. >>> >>>Because of this there is still no chance to interoperate with other >>>vendor appliancies / gateways / vpn clients ncp / cisco etc. which > > use > >>>ipcomp static lzs . >>> >>> >>>Any change to get this security issue / bug solved? >>> >>> >>>Cheers, >>> >>>Andreas >>> >>> >>>------------------------------------------------------- >>>SF.Net email is sponsored by: Tell us your software development > > plans! > >>>Take this survey and enter to win a one-year sub to SourceForge.net >>>Plus IDC's 2005 look-ahead and a copy of this survey >>>Click here to start! > > http://www.idcswdc.com/cgi-bin/survey?id=105hix > >>>_______________________________________________ >>>Ipsec-tools-devel mailing list >>>Ips...@li... >>>https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel >> >>-- >>Aidas Kasparas >>IT administrator >>GM Consult Group, UAB >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Tell us your software development plans! >>Take this survey and enter to win a one-year sub to SourceForge.net >>Plus IDC's 2005 look-ahead and a copy of this survey >>Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix >>_______________________________________________ >>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: Marco B. <pu...@ho...> - 2005-04-29 15:33:40
|
Aidas Kasparas wrote: > spdadd <from> <to> any -P out esp/transport//require > ipcomp/tunnel/84.144.56.4-A.B.C.D/require; > > Ok, not exactly what I suggested in previous post, but in the same > direction. Please try it. Here is: http://lists.openswan.org/pipermail/users/2004-March/000418.html :-(( |
From: Aidas K. <a.k...@gm...> - 2005-04-29 15:45:22
|
Marco Berizzi wrote: > Aidas Kasparas wrote: > > >>spdadd <from> <to> any -P out esp/transport//require >>ipcomp/tunnel/84.144.56.4-A.B.C.D/require; >> >>Ok, not exactly what I suggested in previous post, but in the same >>direction. Please try it. > > > Here is: > > http://lists.openswan.org/pipermail/users/2004-March/000418.html > > :-(( > <*CENSORED*>. How about other implementations? Do they expect tunnel or transport at that point? And, what RFC allows them to do expect tunnel there? -- Aidas Kasparas IT administrator GM Consult Group, UAB |
From: Andreas N. <Andreas.Nobel@FernUni-Hagen.de> - 2005-04-29 16:31:52
|
> <*CENSORED*>. How about other implementations? Do they > expect tunnel or transport at that point? And, what RFC > allows them to do expect tunnel there? Yes, Cisco IOS VPN enabled Routers This proposals work together with Cisco VPN Client... [...] ! crypto ipsec transform-set aes256-md5-comp esp-aes 256 esp-md5-hmac comp-lzs ! [...] and for sure Cisco VPN Client or NCP ones. I don't own products from other vendors, so can anyone sign my results with Racoon IPComp in Tunnel Mode when using products from foreign vendors? Latest RFC for IPComp can be found on this mirror: http://www.faqs.org/rfcs/rfc3173.html This contains the magic keywords "Tunnel Mode" indeed. Andreas |
From: Marco B. <pu...@ho...> - 2005-05-02 07:25:16
|
Aidas Kasparas wrote: > > > Marco Berizzi wrote: > > Aidas Kasparas wrote: > > > > > >>spdadd <from> <to> any -P out esp/transport//require > >>ipcomp/tunnel/84.144.56.4-A.B.C.D/require; > >> > >>Ok, not exactly what I suggested in previous post, but in the same > >>direction. Please try it. > > > > > > Here is: > > > > http://lists.openswan.org/pipermail/users/2004-March/000418.html > > > > :-(( > > > > <*CENSORED*>. How about other implementations? Do they expect tunnel or > transport at that point? And, what RFC allows them to do expect tunnel > there? I only own Linux systems. Sorry. FYI: FreeS/WAN with Linux 2.6 (no KLIPS) interop correctly with FreeS/WAN on Linux 2.4 (KLIPS). |
From: Marco B. <pu...@ho...> - 2005-05-20 12:15:41
|
Aidas Kasparas wrote: > Marco Berizzi wrote: > > Aidas Kasparas wrote: > > > > > >>spdadd <from> <to> any -P out esp/transport//require > >>ipcomp/tunnel/84.144.56.4-A.B.C.D/require; > >> > >>Ok, not exactly what I suggested in previous post, but in the same > >>direction. Please try it. > > > > > > Here is: > > > > http://lists.openswan.org/pipermail/users/2004-March/000418.html > > > > :-(( > > > > <*CENSORED*>. How about other implementations? Do they expect tunnel or > transport at that point? And, what RFC allows them to do expect tunnel > there? According to http://www.vpnc.org/ietf-ipsec/00.ipsec/msg02082.html All modes in each proposals have to be equal. Therefore both need to be tunnel. - RFC2409 requires mode of operation (tunnel/transport) to be the same across all the transforms. If we see "tunnel mode" in transports (note: plural!), we need to encapsulate only once - even though we see "tunnel mode" attribute multiple times, we encapsulate only once. Full message from Michal Ludvig : http://sourceforge.net/mailarchive/message.php?msg_id=6924452 |
From: Marco B. <pu...@ho...> - 2005-07-06 09:34:45
|
Aidas Kasparas wrote: > > > Marco Berizzi wrote: > > Aidas Kasparas wrote: > > > > > >>spdadd <from> <to> any -P out esp/transport//require > >>ipcomp/tunnel/84.144.56.4-A.B.C.D/require; > >> > >>Ok, not exactly what I suggested in previous post, but in the same > >>direction. Please try it. > > > > > > Here is: > > > > http://lists.openswan.org/pipermail/users/2004-March/000418.html > > > > :-(( > > > > <*CENSORED*>. How about other implementations? Do they expect tunnel or > transport at that point? And, what RFC allows them to do expect tunnel > there? Hi Aidas. This morning I have done a stupid thing. I have removed this piece of code from src/racoon/proposal.c /* if (pr1->encmode != pr2->encmode) { plog(LLV_ERROR, LOCATION, NULL, "encmode mismatched: " "my:%s peer:%s\n", s_ipsecdoi_encmode(pr2->encmode), s_ipsecdoi_encmode(pr1->encmode)); goto err; } */ Now racoon and *swan establish the tunnel (packet smaller than 290 bytes are flowing packet bigger aren't, because there are some other know bugs). I would like to know if this source code hack breaks any RFC or racoon. |
From: Aidas K. <a.k...@gm...> - 2005-07-06 13:39:19
|
> Hi Aidas. This morning I have done a stupid thing. I have removed > this piece of code from src/racoon/proposal.c > > /* if (pr1->encmode != pr2->encmode) { plog(LLV_ERROR, LOCATION, > NULL, "encmode mismatched: " "my:%s peer:%s\n", > s_ipsecdoi_encmode(pr2->encmode), s_ipsecdoi_encmode(pr1->encmode)); > goto err; } */ > > Now racoon and *swan establish the tunnel (packet smaller than 290 > bytes are flowing packet bigger aren't, because there are some other > know bugs). I would like to know if this source code hack breaks any > RFC or racoon. > Well, you have allowed to use engine from Fiat Uno in Ferrari: producers are the same, working principles are very close, but I doubt it will work. Speaking about RFCs... RFC2401 clearly distinguishes that "<...>two types of SAs are defined: transport mode and tunnel mode." (4.1) It states that any of them can be used, if policy allows any mode. But it requires a lawyer to proove that in no other case they can be allowed to be used interchangeably. At least I was unable to find such explicit statement quickly. But, I believe you can not close eyes to the mode. -- Aidas Kasparas IT administrator GM Consult Group, UAB |
From: Marco B. <pu...@ho...> - 2005-07-06 16:51:22
|
Aidas Kasparas wrote: > > Hi Aidas. This morning I have done a stupid thing. I have removed > > this piece of code from src/racoon/proposal.c > > > > /* if (pr1->encmode != pr2->encmode) { plog(LLV_ERROR, LOCATION, > > NULL, "encmode mismatched: " "my:%s peer:%s\n", > > s_ipsecdoi_encmode(pr2->encmode), s_ipsecdoi_encmode(pr1->encmode)); > > goto err; } */ > > > > Now racoon and *swan establish the tunnel (packet smaller than 290 > > bytes are flowing packet bigger aren't, because there are some other > > know bugs). I would like to know if this source code hack breaks any > > RFC or racoon. > > > > Well, you have allowed to use engine from Fiat Uno in Ferrari: producers > are the same, working principles are very close, but I doubt it will work. > > Speaking about RFCs... RFC2401 clearly distinguishes that "<...>two > types of SAs are defined: transport mode and tunnel mode." (4.1) It > states that any of them can be used, if policy allows any mode. [mhhh... policy allow ESP in transport mode so RFC is broken by this hack... (?)] > But it > requires a lawyer to proove that in no other case they can be allowed to > be used interchangeably. At least I was unable to find such explicit > statement quickly. But, I believe you can not close eyes to the mode. Ok, I will do some test to find any collateral "feature" with this hack. Thanks. |
From: Aidas K. <a.k...@gm...> - 2005-07-07 06:13:03
|
Marco Berizzi wrote: >>Speaking about RFCs... RFC2401 clearly distinguishes that "<...>two >>types of SAs are defined: transport mode and tunnel mode." (4.1) It >>states that any of them can be used, if policy allows any mode. > > > [mhhh... policy allow ESP in transport mode so RFC is broken by > this hack... (?)] No, ESP/transport is OK according to RFC. But using different modes in different tunnel ends is not. > > Ok, I will do some test to find any collateral "feature" with this hack. > Thanks. > If you'll configure just ESP tunnels with transport on one end and tunnel on another, then racoon will (maybe) negotiate SAs, but systems will not be able to communicate. -- Aidas Kasparas IT administrator GM Consult Group, UAB |