From: Matthew G. <mg...@sh...> - 2006-09-23 22:26:17
|
All, When attempting to use racoon and a manually configured policy that=20 specifies ipcomp as well as esp, I am seeing racoon dump core from a=20 double free. Here is the setkey parameters in use on a FreeBSD=20 6.1-RELEASE system. I suppose its possible that I am specifying the=20 setkey parameters wrong but we don't want racoon to cave in any case. spdadd 10.1.1.1 10.2.1.128 any -P out ipsec=20 esp/tunnel/10.22.200.1-10.22.200.119/unique=20 ipcomp/tunnel/10.22.200.1-10.22.200.119/unique; spdadd 10.2.1.128 10.1.1.1 any -P in ipsec=20 esp/tunnel/10.22.200.119-10.22.200.1/unique=20 ipcomp/tunnel/10.22.200.119-10.22.200.1/unique; I am looking into this but I'm afraid my gdb skills are less than=20 stellar. I was hoping someone that is more familiar with the policy=20 matching code can fix it before I can as it would be good to do before=20 0.7 branches. The extra ret =3D %p's at the end of the output are just=20 some debug checks I put in to see if the ret pointer was getting trashed=20 somewhere. The offense appears to occur at free_proppair0(ret) ( ipsec_doi.c ~ line=20 895 ) in the ipsecdoi_selectph2proposal function. 2006-09-23 14:54:01: DEBUG: begin. 2006-09-23 14:54:01: DEBUG: seen nptype=3D2(prop) 2006-09-23 14:54:01: DEBUG: seen nptype=3D2(prop) 2006-09-23 14:54:01: DEBUG: succeed. 2006-09-23 14:54:01: DEBUG: proposal #1 len=3D36 2006-09-23 14:54:01: DEBUG: begin. 2006-09-23 14:54:01: DEBUG: seen nptype=3D3(trns) 2006-09-23 14:54:01: DEBUG: succeed. 2006-09-23 14:54:01: DEBUG: transform #1 len=3D24 2006-09-23 14:54:01: DEBUG: type=3D4, flag=3D0x8000, lorv=3D0x0001 2006-09-23 14:54:01: DEBUG: type=3D1, flag=3D0x8000, lorv=3D0x0001 2006-09-23 14:54:01: DEBUG: type=3D2, flag=3D0x0000, lorv=3D0x0004 2006-09-23 14:54:01: DEBUG: proposal #1 len=3D40 2006-09-23 14:54:01: DEBUG: begin. 2006-09-23 14:54:01: DEBUG: seen nptype=3D3(trns) 2006-09-23 14:54:01: DEBUG: succeed. 2006-09-23 14:54:01: DEBUG: transform #1 len=3D28 2006-09-23 14:54:01: DEBUG: type=3DEncryption Mode, flag=3D0x8000, lorv=3D= Tunnel 2006-09-23 14:54:01: DEBUG: type=3DAuthentication Algorithm, flag=3D0x800= 0,=20 lorv=3Dhmac-md5 2006-09-23 14:54:01: DEBUG: type=3DSA Life Type, flag=3D0x8000, lorv=3Dse= conds 2006-09-23 14:54:01: DEBUG: type=3DSA Life Duration, flag=3D0x0000, lorv=3D= 4 2006-09-23 14:54:01: DEBUG: pair 1: 2006-09-23 14:54:01: DEBUG: 0x80bbb00: next=3D0x80bbb10 tnext=3D0x0 2006-09-23 14:54:01: DEBUG: 0x80bbb10: next=3D0x0 tnext=3D0x0 2006-09-23 14:54:01: DEBUG: proposal #1: 2 transform 2006-09-23 14:54:01: DEBUG: begin compare proposals. 2006-09-23 14:54:01: DEBUG: pair[1]: 0x80bbb00 2006-09-23 14:54:01: DEBUG: 0x80bbb00: next=3D0x80bbb10 tnext=3D0x0 2006-09-23 14:54:01: DEBUG: 0x80bbb10: next=3D0x0 tnext=3D0x0 2006-09-23 14:54:01: DEBUG: prop#=3D1 prot-id=3DIPCOMP spi-size=3D4 #trns= =3D1=20 trns#=3D1 trns-id=3DDEFLATE 2006-09-23 14:54:01: DEBUG: type=3DEncryption Mode, flag=3D0x8000, lorv=3D= Tunnel 2006-09-23 14:54:01: DEBUG: type=3DSA Life Type, flag=3D0x8000, lorv=3Dse= conds 2006-09-23 14:54:01: DEBUG: type=3DSA Life Duration, flag=3D0x0000, lorv=3D= 4 2006-09-23 14:54:01: DEBUG: prop#=3D1 prot-id=3DESP spi-size=3D4 #trns=3D= 1=20 trns#=3D1 trns-id=3D3DES 2006-09-23 14:54:01: DEBUG: type=3DEncryption Mode, flag=3D0x8000, lorv=3D= Tunnel 2006-09-23 14:54:01: DEBUG: type=3DAuthentication Algorithm, flag=3D0x800= 0,=20 lorv=3Dhmac-md5 2006-09-23 14:54:01: DEBUG: type=3DSA Life Type, flag=3D0x8000, lorv=3Dse= conds 2006-09-23 14:54:01: DEBUG: type=3DSA Life Duration, flag=3D0x0000, lorv=3D= 4 2006-09-23 14:54:01: DEBUG: peer's single bundle: 2006-09-23 14:54:01: DEBUG: (proto_id=3DIPCOMP spisize=3D4 spi=3D053b323= 7=20 spi_p=3D00000000 encmode=3DTunnel reqid=3D0:0) 2006-09-23 14:54:01: DEBUG: (trns_id=3DDEFLATE) 2006-09-23 14:54:01: DEBUG: (proto_id=3DESP spisize=3D4 spi=3D053b3237=20 spi_p=3D00000000 encmode=3DTunnel reqid=3D0:0) 2006-09-23 14:54:01: DEBUG: (trns_id=3D3DES encklen=3D0 authtype=3Dhmac= -md5) 2006-09-23 14:54:01: DEBUG: my single bundle: 2006-09-23 14:54:01: DEBUG: (proto_id=3DIPCOMP spisize=3D2 spi=3D0000000= 0=20 spi_p=3D00000000 encmode=3DTunnel reqid=3D16609:16606) 2006-09-23 14:54:01: DEBUG: (trns_id=3DDEFLATE) 2006-09-23 14:54:01: DEBUG: (proto_id=3DESP spisize=3D4 spi=3D00000000=20 spi_p=3D00000000 encmode=3DTunnel reqid=3D16608:16607) 2006-09-23 14:54:01: DEBUG: (trns_id=3D3DES encklen=3D0 authtype=3Dhmac= -md5) 2006-09-23 14:54:01: ERROR: IPComp SPI size promoted from 16bit to 32bit 2006-09-23 14:54:01: DEBUG: matched 2006-09-23 14:54:01: ERROR: ret =3D 0x80bbae0. 2006-09-23 14:54:01: ERROR: ret =3D 0x80bbae0. 2006-09-23 14:54:01: ERROR: ret =3D 0x80bbae0. racoon in free(): error: chunk is already free Abort trap: 6 (core dumped) Here is what gdb spits out as a back trace ... Program received signal SIGABRT, Aborted. 0x28345363 in kill () from /lib/libc.so.6 (gdb) bt #0 0x28345363 in kill () from /lib/libc.so.6 #1 0x28345300 in raise () from /lib/libc.so.6 #2 0x28344014 in abort () from /lib/libc.so.6 #3 0x282ea4d3 in _UTF8_init () from /lib/libc.so.6 #4 0xbfbfed57 in ?? () #5 0x2834b4d7 in sys_nsig () from /lib/libc.so.6 #6 0x2834b3d7 in sys_nsig () from /lib/libc.so.6 #7 0x2834b434 in sys_nsig () from /lib/libc.so.6 #8 0x00000000 in ?? () #9 0x28355508 in ?? () from /lib/libc.so.6 #10 0xbfbfe228 in ?? () #11 0x282ea501 in _UTF8_init () from /lib/libc.so.6 #12 0x28355508 in ?? () from /lib/libc.so.6 #13 0x080a8d4c in _CurrentRuneLocale () #14 0xbfbfe2d8 in ?? () #15 0x282eb261 in _UTF8_init () from /lib/libc.so.6 #16 0x28355298 in __sF () from /lib/libc.so.6 #17 0x080a9740 in logp () #18 0xbfbfe2f4 in ?? () #19 0x00000000 in ?? () #20 0x00000320 in ?? () #21 0x08097ef1 in __func__.1 () #22 0x080a8d4c in _CurrentRuneLocale () #23 0x28355508 in ?? () from /lib/libc.so.6 #24 0x00000001 in ?? () #25 0x00000001 in ?? () #26 0x00000000 in ?? () #27 0x00000000 in ?? () #28 0x28355298 in __sF () from /lib/libc.so.6 #29 0x080a9740 in logp () #30 0xbfbfe2f0 in ?? () #31 0x00000000 in ?? () #32 0x00000001 in ?? () #33 0x00000001 in ?? () #34 0xbfbfe2a8 in ?? () #35 0x08076f2b in plogv (pri=3D134986464, func=3D0x80a8d4c "",=20 sa=3D0xbfbfe2d8, fmt=3D0x282eb261 "\213\213=B4f", ap=3D0x28355298 "") at = plog.c:173 Previous frame inner to this frame (corrupt stack?) Anybody? Thanks, -Matthew |
From: <ma...@ne...> - 2006-09-23 22:32:23
|
Matthew Grooms <mg...@sh...> wrote: > I am looking into this but I'm afraid my gdb skills are less than > stellar. Link racoon with electric-fence. You'll find the source of the problem almost immediatly. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: Matthew G. <mg...@sh...> - 2006-09-23 22:52:57
|
Emmanuel Dreyfus wrote: > Matthew Grooms <mg...@sh...> wrote: > >> I am looking into this but I'm afraid my gdb skills are less than >> stellar. > > Link racoon with electric-fence. You'll find the source of the problem > almost immediatly. > Thanks, that helps a bit. At least now I'm getting a back trace from a stack that isn't trashed ... Program received signal SIGBUS, Bus error. free_proppair0 (pair=0x2943aff0) at ipsec_doi.c:1263 1263 s = r->tnext; (gdb) bt #0 free_proppair0 (pair=0x2943aff0) at ipsec_doi.c:1263 #1 0x080654c1 in ipsecdoi_selectph2proposal (iph2=0x29398f68) at ipsec_doi.c:895 #2 0x0805b317 in quick_r1recv (iph2=0x29398f68, msg0=0x29354ff8) at isakmp_quick.c:1089 #3 0x0805012d in isakmp_main (msg=0x29354ff8, remote=0xbfbfe5f0, local=0xbfbfe570) at isakmp.c:1411 #4 0x08050892 in isakmp_handler (so_isakmp=11) at isakmp.c:381 #5 0x0804c7d0 in session () at session.c:223 #6 0x0804c12f in main (ac=0, av=0xbfbfec44) at main.c:260 I guess this points to get_ph2approval(iph2, pair) not setting a tnext pointer correctly. The offending code must be under a conditional that doesn't get exercised very often :( -Matthew |
From: Matthew G. <mg...@sh...> - 2006-09-25 00:01:04
Attachments:
propfix.diff
|
All, This fixes the double free I was seeing. I disabled the offending code section and added some comments for future reference. The idea was to leave things transparent if it was added in an attempt to plug a memory leak. I'm also looking into modifying the policy generation to work with chained proposals. The current process doesn't allow for options like ipcomp. Thanks, -Matthew |
From: <ma...@ne...> - 2006-09-25 04:56:23
|
Matthew Grooms <mg...@sh...> wrote: > + /* > + * why was n being freed here? it needs > + * to be preserved or we will get a > + * duplicate free when free_proppair0 > + * is called later > + */ > +#ifdef 0 > if (n != NULL) > racoon_free(n); > +#endif > > n = racoon_calloc(1, sizeof(struct prop_pair)); > if (n == NULL) { I am the one to blame, as I added this racoon_free(). I was attempting to fix a memory leak reported by Coverity, but I misunderstood the way the code worked. I checked your fix in. The memory leak is probably back. If you have some spare time, register at http://scan.coverity.com:7449, and look at the ipsec-tools bugs in src/crypto/dist. There are about 50 bugs remaining. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From:
<llu...@hp...> - 2006-09-25 07:47:10
Attachments:
smime.p7s
|
Emmanuel Dreyfus wrote: > I am the one to blame, as I added this racoon_free(). I was attempting > to fix a memory leak reported by Coverity, but I misunderstood the way > the code worked. >=20 > I checked your fix in. The memory leak is probably back. If you have > some spare time, register at http://scan.coverity.com:7449, and look at > the ipsec-tools bugs in src/crypto/dist. There are about 50 bugs > remaining. >=20 I'd also like to see the buglist. How can I register there? I can only see a login form. Thanks in advance, --=20 Llu=EDs Batlle i Rossell - Ext. (+34 93 58) 26667 - Cubicle 25 J llu...@ja... |
From: Emmanuel D. <ma...@ne...> - 2006-09-25 07:50:42
|
On Mon, Sep 25, 2006 at 09:46:58AM +0200, "Batlle i Rossell, Llu=EDs" wro= te: > >I checked your fix in. The memory leak is probably back. If you have > >some spare time, register at http://scan.coverity.com:7449, and look a= t > >the ipsec-tools bugs in src/crypto/dist. There are about 50 bugs > >remaining. > > > I'd also like to see the buglist. How can I register there? I can only > see a login form. Sorry, here is the main site: http://scan.coverity.com/ --=20 Emmanuel Dreyfus ma...@ne... |
From: Matthew G. <mg...@sh...> - 2006-09-25 19:51:51
|
All, Has anyone tried to use bundled SAs in head? Even after the double free bug was corrected, it doesn't appear to be working for me. I have configured the following policies on a FreeBSD 6.1 host ... spdadd 10.1.1.2 10.2.1.128 any -P out ipsec ipcomp/tunnel/10.22.200.1-10.22.200.119/unique esp/transport//unique; spdadd 10.2.1.128 10.1.1.2 any -P in ipsec ipcomp/tunnel/10.22.200.1-10.22.200.119/unique esp/transport//unique; ... which I hope would mean the following for processing outbound packets ( the verbiage in the setkey(8) confuses me ) ... 1) Encrypt the packet using ESP ( transport, no new ip header ) 2) Compress the packet using IPCOMP ( tunnel, add new ip header ) I want this order as IPCOMP says that you need to do compression after encryption. After setkey is run, I get these new entries in SPD ... su-2.05b# setkey -DP 10.2.1.128[any] 10.1.1.2[any] any in ipsec ipcomp/tunnel/10.22.200.1-10.22.200.119/unique#16946 esp/transport//unique#16947 spid=2743 seq=6 pid=65412 refcnt=1 10.1.1.2[any] 10.2.1.128[any] any out ipsec ipcomp/tunnel/10.22.200.1-10.22.200.119/unique#16944 esp/transport//unique#16945 spid=2742 seq=0 pid=65412 refcnt=1 ... which looks reasonable to me. The problem occurs after racoon attempts to establish the SA bundle as a responder. The new SAD entries are created but *the SPD entries vanish*. Here is the pertinent racoon output ... 2006-09-25 11:53:27: DEBUG: suitable SP found:10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: (proto_id=ESP spisize=4 spi=00000000 spi_p=00000000 encmode=Transport reqid=16917:16914) 2006-09-25 11:53:27: DEBUG: (trns_id=3DES encklen=0 authtype=hmac-md5) 2006-09-25 11:53:27: DEBUG: (proto_id=IPCOMP spisize=2 spi=00000000 spi_p=00000000 encmode=Tunnel reqid=16916:16915) 2006-09-25 11:53:27: DEBUG: (trns_id=DEFLATE) 2006-09-25 11:53:27: DEBUG: total SA len=84 2006-09-25 11:53:27: DEBUG: 00000001 00000001 02000024 01040401 2f71b8e9 00000018 01020000 80040001 80010001 00020004 00000e10 00000028 01030401 e9b8712f 0000001c 01030000 80040002 80050001 80010001 00020004 00000e10 2006-09-25 11:53:27: DEBUG: begin. 2006-09-25 11:53:27: DEBUG: seen nptype=2(prop) 2006-09-25 11:53:27: DEBUG: seen nptype=2(prop) 2006-09-25 11:53:27: DEBUG: succeed. 2006-09-25 11:53:27: DEBUG: proposal #1 len=36 2006-09-25 11:53:27: DEBUG: begin. 2006-09-25 11:53:27: DEBUG: seen nptype=3(trns) 2006-09-25 11:53:27: DEBUG: succeed. 2006-09-25 11:53:27: DEBUG: transform #1 len=24 2006-09-25 11:53:27: DEBUG: type=4, flag=0x8000, lorv=0x0001 2006-09-25 11:53:27: DEBUG: type=1, flag=0x8000, lorv=0x0001 2006-09-25 11:53:27: DEBUG: type=2, flag=0x0000, lorv=0x0004 2006-09-25 11:53:27: DEBUG: proposal #1 len=40 2006-09-25 11:53:27: DEBUG: begin. 2006-09-25 11:53:27: DEBUG: seen nptype=3(trns) 2006-09-25 11:53:27: DEBUG: succeed. 2006-09-25 11:53:27: DEBUG: transform #1 len=28 2006-09-25 11:53:27: DEBUG: type=Encryption Mode, flag=0x8000, lorv=Transport 2006-09-25 11:53:27: DEBUG: type=Authentication Algorithm, flag=0x8000, lorv=hmac-md5 2006-09-25 11:53:27: DEBUG: type=SA Life Type, flag=0x8000, lorv=seconds 2006-09-25 11:53:27: DEBUG: type=SA Life Duration, flag=0x0000, lorv=4 2006-09-25 11:53:27: DEBUG: pair 1: 2006-09-25 11:53:27: DEBUG: 0x29436ff0: next=0x29438ff0 tnext=0x0 2006-09-25 11:53:27: DEBUG: 0x29438ff0: next=0x0 tnext=0x0 2006-09-25 11:53:27: DEBUG: proposal #1: 2 transform 2006-09-25 11:53:27: DEBUG: begin compare proposals. 2006-09-25 11:53:27: DEBUG: pair[1]: 0x29436ff0 2006-09-25 11:53:27: DEBUG: 0x29436ff0: next=0x29438ff0 tnext=0x0 2006-09-25 11:53:27: DEBUG: 0x29438ff0: next=0x0 tnext=0x0 2006-09-25 11:53:27: DEBUG: prop#=1 prot-id=IPCOMP spi-size=4 #trns=1 trns#=1 trns-id=DEFLATE 2006-09-25 11:53:27: DEBUG: type=Encryption Mode, flag=0x8000, lorv=Tunnel 2006-09-25 11:53:27: DEBUG: type=SA Life Type, flag=0x8000, lorv=seconds 2006-09-25 11:53:27: DEBUG: type=SA Life Duration, flag=0x0000, lorv=4 2006-09-25 11:53:27: DEBUG: prop#=1 prot-id=ESP spi-size=4 #trns=1 trns#=1 trns-id=3DES 2006-09-25 11:53:27: DEBUG: type=Encryption Mode, flag=0x8000, lorv=Transport 2006-09-25 11:53:27: DEBUG: type=Authentication Algorithm, flag=0x8000, lorv=hmac-md5 2006-09-25 11:53:27: DEBUG: type=SA Life Type, flag=0x8000, lorv=seconds 2006-09-25 11:53:27: DEBUG: type=SA Life Duration, flag=0x0000, lorv=4 2006-09-25 11:53:27: DEBUG: peer's single bundle: 2006-09-25 11:53:27: DEBUG: (proto_id=IPCOMP spisize=4 spi=2f71b8e9 spi_p=00000000 encmode=Tunnel reqid=0:0) 2006-09-25 11:53:27: DEBUG: (trns_id=DEFLATE) 2006-09-25 11:53:27: DEBUG: (proto_id=ESP spisize=4 spi=e9b8712f spi_p=00000000 encmode=Transport reqid=0:0) 2006-09-25 11:53:27: DEBUG: (trns_id=3DES encklen=0 authtype=hmac-md5) 2006-09-25 11:53:27: DEBUG: my single bundle: 2006-09-25 11:53:27: DEBUG: (proto_id=ESP spisize=4 spi=00000000 spi_p=00000000 encmode=Transport reqid=16917:16914) 2006-09-25 11:53:27: DEBUG: (trns_id=3DES encklen=0 authtype=hmac-md5) 2006-09-25 11:53:27: DEBUG: (proto_id=IPCOMP spisize=2 spi=00000000 spi_p=00000000 encmode=Tunnel reqid=16916:16915) 2006-09-25 11:53:27: DEBUG: (trns_id=DEFLATE) 2006-09-25 11:53:27: ERROR: IPComp SPI size promoted from 16bit to 32bit 2006-09-25 11:53:27: DEBUG: matched 2006-09-25 11:53:27: DEBUG: === 2006-09-25 11:53:27: DEBUG: call pfkey_send_getspi 2006-09-25 11:53:27: DEBUG: pfkey GETSPI sent: ESP/Transport 10.22.200.119[0]->10.22.200.1[0] 2006-09-25 11:53:27: DEBUG: call pfkey_send_getspi 2006-09-25 11:53:27: DEBUG: pfkey GETSPI sent: IPCOMP/Tunnel 10.22.200.119[0]->10.22.200.1[0] 2006-09-25 11:53:27: DEBUG: pfkey getspi sent. 2006-09-25 11:53:27: DEBUG: get pfkey GETSPI message 2006-09-25 11:53:27: DEBUG: pfkey GETSPI succeeded: ESP/Transport 10.22.200.119[0]->10.22.200.1[0] spi=241920772(0xe6b6b04) 2006-09-25 11:53:27: DEBUG: get pfkey GETSPI message 2006-09-25 11:53:27: DEBUG: pfkey GETSPI succeeded: IPCOMP/Tunnel 10.22.200.119[0]->10.22.200.1[0] spi=13919(0x365f) 2006-09-25 11:53:27: DEBUG: total SA len=84 ... 2006-09-25 11:53:27: DEBUG: KEYMAT computed. 2006-09-25 11:53:27: DEBUG: call pk_sendupdate 2006-09-25 11:53:27: DEBUG: encryption(3des) 2006-09-25 11:53:27: DEBUG: hmac(hmac_md5) 2006-09-25 11:53:27: DEBUG: call pfkey_send_update 2006-09-25 11:53:27: DEBUG: call pfkey_send_update 2006-09-25 11:53:27: DEBUG: pfkey update sent. 2006-09-25 11:53:27: DEBUG: encryption(3des) 2006-09-25 11:53:27: DEBUG: hmac(hmac_md5) 2006-09-25 11:53:27: DEBUG: call pfkey_send_add 2006-09-25 11:53:27: DEBUG: call pfkey_send_add 2006-09-25 11:53:27: DEBUG: pfkey add sent. 2006-09-25 11:53:27: DEBUG: call pfkey_send_spdupdate2 2006-09-25 11:53:27: DEBUG: pfkey spdupdate2(inbound) sent. 2006-09-25 11:53:27: DEBUG: call pfkey_send_spdupdate2 2006-09-25 11:53:27: DEBUG: pfkey spdupdate2(outbound) sent. 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.2.1.128/32[0] 10.1.1.2/32[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: db :0x292deee8: 10.20.0.0/16[0] 10.22.200.0/24[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.2.1.128/32[0] 10.1.1.2/32[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: db :0x292e2ee8: 10.23.0.0/16[0] 10.22.200.0/24[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.2.1.128/32[0] 10.1.1.2/32[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: db :0x292e6ee8: 10.200.0.0/16[0] 10.22.200.0/24[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.2.1.128/32[0] 10.1.1.2/32[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: db :0x292eaee8: 10.220.0.0/16[0] 10.22.200.0/24[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.2.1.128/32[0] 10.1.1.2/32[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: db :0x292eeee8: 10.20.0.0/16[0] 10.21.210.0/24[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.2.1.128/32[0] 10.1.1.2/32[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: db :0x292f2ee8: 10.2.1.128/32[0] 10.1.1.2/32[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: db :0x292deee8: 10.20.0.0/16[0] 10.22.200.0/24[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: db :0x292e2ee8: 10.23.0.0/16[0] 10.22.200.0/24[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: db :0x292e6ee8: 10.200.0.0/16[0] 10.22.200.0/24[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: db :0x292eaee8: 10.220.0.0/16[0] 10.22.200.0/24[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: db :0x292eeee8: 10.20.0.0/16[0] 10.21.210.0/24[0] proto=any dir=in 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: db :0x292f8ee8: 10.22.200.0/24[0] 10.20.0.0/16[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: db :0x292fcee8: 10.22.200.0/24[0] 10.23.0.0/16[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: db :0x29300ee8: 10.22.200.0/24[0] 10.200.0.0/16[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: db :0x29304ee8: 10.22.200.0/24[0] 10.220.0.0/16[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: db :0x29308ee8: 10.21.210.0/24[0] 10.20.0.0/16[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: sub:0xbfbfe340: 10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: db :0x2930cee8: 10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out 2006-09-25 11:53:27: DEBUG: get pfkey UPDATE message 2006-09-25 11:53:27: DEBUG: pfkey UPDATE succeeded: ESP/Transport 10.22.200.119[0]->10.22.200.1[0] spi=241920772(0xe6b6b04) 2006-09-25 11:53:27: INFO: IPsec-SA established: ESP/Transport 10.22.200.119[0]->10.22.200.1[0] spi=241920772(0xe6b6b04) 2006-09-25 11:53:27: DEBUG: get pfkey UPDATE message 2006-09-25 11:53:27: DEBUG: pfkey UPDATE succeeded: IPCOMP/Tunnel 10.22.200.119[0]->10.22.200.1[0] spi=13919(0x365f) 2006-09-25 11:53:27: INFO: IPsec-SA established: IPCOMP/Tunnel 10.22.200.119[0]->10.22.200.1[0] spi=13919(0x365f) 2006-09-25 11:53:27: DEBUG: === 2006-09-25 11:53:27: DEBUG: get pfkey ADD message 2006-09-25 11:53:27: INFO: IPsec-SA established: ESP/Transport 10.22.200.1[0]->10.22.200.119[0] spi=3921178927(0xe9b8712f) 2006-09-25 11:53:27: DEBUG: === 2006-09-25 11:53:27: DEBUG: get pfkey ADD message 2006-09-25 11:53:27: INFO: IPsec-SA established: IPCOMP/Tunnel 10.22.200.1[0]->10.22.200.119[0] spi=795982057(0x2f71b8e9) 2006-09-25 11:53:27: DEBUG: === 2006-09-25 11:53:27: DEBUG: get pfkey X_SPDUPDATE message 2006-09-25 11:53:27: ERROR: pfkey X_SPDUPDATE failed: Invalid argument 2006-09-25 11:53:27: DEBUG: get pfkey X_SPDUPDATE message 2006-09-25 11:53:27: ERROR: pfkey X_SPDUPDATE failed: Invalid argument ... What does a X_SPDUPDATE message do and could it be responsible for removing a policy from SPD? I just started looking at this area of code a few days ago. While I have a decent grasp on most IPSEC related stuff, th key interface stuff is still a mystery to me. Being so near to 0.7, it would be good to get the problem resolved. Could someone with more PF_KEY knowledge please have a look at this? Thanks in advance, -Matthew |
From: <ma...@ne...> - 2006-09-25 20:18:08
|
Matthew Grooms <mg...@sh...> wrote: > Has anyone tried to use bundled SAs in head? Even after the double free > bug was corrected, it doesn't appear to be working for me. I never managed to get ESP+IPcomp working, despite intensive hacking. I gave up with that feature. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: Matthew G. <mg...@sh...> - 2006-09-25 20:58:16
|
Emmanuel Dreyfus wrote: > Matthew Grooms <mg...@sh...> wrote: > >> Has anyone tried to use bundled SAs in head? Even after the double free >> bug was corrected, it doesn't appear to be working for me. > > I never managed to get ESP+IPcomp working, despite intensive hacking. I > gave up with that feature. > It must have been working at some point. It would be nice to get this feature fixed if possible. I will give it a shot but seriously doubt I will fair any better. As a starting point, I assume your test platform was NetBSD. Were you able to rule issues related to kernel support? Thanks, -Matthew |
From: <ma...@ne...> - 2006-09-25 21:51:15
|
Matthew Grooms <mg...@sh...> wrote: > It must have been working at some point. It would be nice to get this > feature fixed if possible. I will give it a shot but seriously doubt I > will fair any better. As a starting point, I assume your test platform > was NetBSD. Were you able to rule issues related to kernel support? Have a look at the list archive in 2005, starting on april 27th. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: Jeff B. <jef...@in...> - 2006-09-25 22:20:13
|
Related to bundled SA I know that for anonymous initiator it was broken. I submitted a patch for that particular issue on June 17. That patch fixed AH+ESP for me. I do not know about IPcomp. I tried to use IPcomp but gave up on it. The patch for bundling from anonymous inititator is on sourcforge in the upload patches place. regards Jeff > Emmanuel Dreyfus wrote: >> Matthew Grooms <mg...@sh...> wrote: >> >>> Has anyone tried to use bundled SAs in head? Even after the >>> double free >>> bug was corrected, it doesn't appear to be working for me. >> >> I never managed to get ESP+IPcomp working, despite intensive hacking. >> I gave up with that feature. >> > > It must have been working at some point. It would be nice to get this > feature fixed if possible. I will give it a shot but seriously doubt I > will fair any better. As a starting point, I assume your test platform > was NetBSD. Were you able to rule issues related to kernel support? > > Thanks, > > -Matthew > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel Office 510-745-0408 FAX 510-745-7447 Cell 510-579-7314 or 697-0317 |
From: Matthew G. <mg...@sh...> - 2006-09-25 23:07:51
|
Jeff Bailey wrote: > Related to bundled SA I know that for anonymous initiator it was broken. > I submitted a patch for that particular issue on June 17. That patch > fixed AH+ESP for me. I do not know about IPcomp. I tried to use IPcomp > but gave up on it. The patch for bundling from anonymous inititator is on > sourcforge > in the upload patches place. Jeff, Thanks for the input. Hopefully your patch fixes the problem I just ran across during pfkey acquire using an anonymous sainfo section. As far as IPcomp goes, I was able to determine that racoon is attempting to overwrite an existing policy in quick_r3prep. The iph2->spidx_gen variable is getting set to true even though its adding SAD entries for a policy that it previously matched in SPD ... 2006-09-25 11:53:27: DEBUG: suitable SP found:10.1.1.2/32[0] 10.2.1.128/32[0] proto=any dir=out ... 2006-09-25 11:53:27: DEBUG: matched 2006-09-25 11:53:27: DEBUG: === 2006-09-25 11:53:27: DEBUG: call pfkey_send_getspi 2006-09-25 11:53:27: DEBUG: pfkey GETSPI sent: ESP/Transport 10.22.200.119[0]->10.22.200.1[0] 2006-09-25 11:53:27: DEBUG: call pfkey_send_getspi 2006-09-25 11:53:27: DEBUG: pfkey GETSPI sent: IPCOMP/Tunnel 10.22.200.119[0]->10.22.200.1[0] 2006-09-25 11:53:27: DEBUG: pfkey getspi sent. 2006-09-25 11:53:27: DEBUG: get pfkey GETSPI message 2006-09-25 11:53:27: DEBUG: pfkey GETSPI succeeded: ESP/Transport 10.22.200.119[0]->10.22.200.1[0] spi=241920772(0xe6b6b04) 2006-09-25 11:53:27: DEBUG: get pfkey GETSPI message 2006-09-25 11:53:27: DEBUG: pfkey GETSPI succeeded: IPCOMP/Tunnel 10.22.200.119[0]->10.22.200.1[0] spi=13919(0x365f) 2006-09-25 11:53:27: DEBUG: total SA len=84 ... 2006-09-25 11:53:27: DEBUG: KEYMAT computed. 2006-09-25 11:53:27: DEBUG: call pk_sendupdate 2006-09-25 11:53:27: DEBUG: encryption(3des) 2006-09-25 11:53:27: DEBUG: hmac(hmac_md5) 2006-09-25 11:53:27: DEBUG: call pfkey_send_update 2006-09-25 11:53:27: DEBUG: call pfkey_send_update 2006-09-25 11:53:27: DEBUG: pfkey update sent. 2006-09-25 11:53:27: DEBUG: encryption(3des) 2006-09-25 11:53:27: DEBUG: hmac(hmac_md5) 2006-09-25 11:53:27: DEBUG: call pfkey_send_add 2006-09-25 11:53:27: DEBUG: call pfkey_send_add 2006-09-25 11:53:27: DEBUG: pfkey add sent. 2006-09-25 11:53:27: DEBUG: call pfkey_send_spdupdate2 2006-09-25 11:53:27: DEBUG: pfkey spdupdate2(inbound) sent. 2006-09-25 11:53:27: DEBUG: call pfkey_send_spdupdate2 2006-09-25 11:53:27: DEBUG: pfkey spdupdate2(outbound) sent. ... 006-09-25 11:53:27: DEBUG: get pfkey UPDATE message 2006-09-25 11:53:27: DEBUG: pfkey UPDATE succeeded: ESP/Transport 10.22.200.119[0]->10.22.200.1[0] spi=241920772(0xe6b6b04) 2006-09-25 11:53:27: INFO: IPsec-SA established: ESP/Transport 10.22.200.119[0]->10.22.200.1[0] spi=241920772(0xe6b6b04) 2006-09-25 11:53:27: DEBUG: get pfkey UPDATE message 2006-09-25 11:53:27: DEBUG: pfkey UPDATE succeeded: IPCOMP/Tunnel 10.22.200.119[0]->10.22.200.1[0] spi=13919(0x365f) 2006-09-25 11:53:27: INFO: IPsec-SA established: IPCOMP/Tunnel 10.22.200.119[0]->10.22.200.1[0] spi=13919(0x365f) 2006-09-25 11:53:27: DEBUG: === 2006-09-25 11:53:27: DEBUG: get pfkey ADD message 2006-09-25 11:53:27: INFO: IPsec-SA established: ESP/Transport 10.22.200.1[0]->10.22.200.119[0] spi=3921178927(0xe9b8712f) 2006-09-25 11:53:27: DEBUG: === 2006-09-25 11:53:27: DEBUG: get pfkey ADD message 2006-09-25 11:53:27: INFO: IPsec-SA established: IPCOMP/Tunnel 10.22.200.1[0]->10.22.200.119[0] spi=795982057(0x2f71b8e9) 2006-09-25 11:53:27: DEBUG: === 2006-09-25 11:53:27: DEBUG: get pfkey X_SPDUPDATE message 2006-09-25 11:53:27: ERROR: pfkey X_SPDUPDATE failed: Invalid argument 2006-09-25 11:53:27: DEBUG: get pfkey X_SPDUPDATE message 2006-09-25 11:53:27: ERROR: pfkey X_SPDUPDATE failed: Invalid argument ... but I'm not sure why yet. After adding an ugly hack to disable the policy generation, I no longer see these ... 2006-09-25 11:53:27: DEBUG: call pfkey_send_spdupdate2 2006-09-25 11:53:27: DEBUG: pfkey spdupdate2(inbound) sent. 2006-09-25 11:53:27: DEBUG: call pfkey_send_spdupdate2 2006-09-25 11:53:27: DEBUG: pfkey spdupdate2(outbound) sent. ... 2006-09-25 11:53:27: DEBUG: === 2006-09-25 11:53:27: DEBUG: get pfkey X_SPDUPDATE message 2006-09-25 11:53:27: ERROR: pfkey X_SPDUPDATE failed: Invalid argument 2006-09-25 11:53:27: DEBUG: get pfkey X_SPDUPDATE message 2006-09-25 11:53:27: ERROR: pfkey X_SPDUPDATE failed: Invalid argument ... which is a step in the right direction. Thanks, -Matthew |
From: Matthew G. <mg...@sh...> - 2006-09-26 00:05:50
Attachments:
bundlefix.diff
|
Jeff Bailey wrote: > Related to bundled SA I know that for anonymous initiator it was broken. > I submitted a patch for that particular issue on June 17. That patch > fixed AH+ESP for me. I do not know about IPcomp. I tried to use IPcomp > but gave up on it. The patch for bundling from anonymous inititator is on > sourcforge > in the upload patches place. > Nice work!!! Hopefully this is one less thing to fix. It looks like racoon generates the policy correctly now for a bundled sa. To test it before I had to add one by hand. I have attached a version of your patch that cleanly applies to head. There was a conflict with the 'generate_policy unique' changes. Maybe Emmanuel can review this and get it committed. I am still seeing other issues but they were present before applying your patch. Revised output ... 2006-09-25 16:48:12: DEBUG: begin. 2006-09-25 16:48:12: DEBUG: seen nptype=2(prop) 2006-09-25 16:48:12: DEBUG: seen nptype=2(prop) 2006-09-25 16:48:12: DEBUG: succeed. 2006-09-25 16:48:12: DEBUG: proposal #1 len=36 2006-09-25 16:48:12: DEBUG: begin. 2006-09-25 16:48:12: DEBUG: seen nptype=3(trns) 2006-09-25 16:48:12: DEBUG: succeed. 2006-09-25 16:48:12: DEBUG: transform #1 len=24 2006-09-25 16:48:12: DEBUG: type=4, flag=0x8000, lorv=0x0001 2006-09-25 16:48:12: DEBUG: type=1, flag=0x8000, lorv=0x0001 2006-09-25 16:48:12: DEBUG: type=2, flag=0x0000, lorv=0x0004 2006-09-25 16:48:12: DEBUG: proposal #1 len=40 2006-09-25 16:48:12: DEBUG: begin. 2006-09-25 16:48:12: DEBUG: seen nptype=3(trns) 2006-09-25 16:48:12: DEBUG: succeed. 2006-09-25 16:48:12: DEBUG: transform #1 len=28 2006-09-25 16:48:12: DEBUG: type=Encryption Mode, flag=0x8000, lorv=Transport 2006-09-25 16:48:12: DEBUG: type=Authentication Algorithm, flag=0x8000, lorv=hmac-md5 2006-09-25 16:48:12: DEBUG: type=SA Life Type, flag=0x8000, lorv=seconds 2006-09-25 16:48:12: DEBUG: type=SA Life Duration, flag=0x0000, lorv=4 2006-09-25 16:48:12: DEBUG: pair 1: 2006-09-25 16:48:12: DEBUG: 0x29421ff0: next=0x29423ff0 tnext=0x0 2006-09-25 16:48:12: DEBUG: 0x29423ff0: next=0x0 tnext=0x0 2006-09-25 16:48:12: DEBUG: proposal #1: 2 transform 2006-09-25 16:48:12: DEBUG: begin compare proposals. 2006-09-25 16:48:12: DEBUG: pair[1]: 0x29421ff0 2006-09-25 16:48:12: DEBUG: 0x29421ff0: next=0x29423ff0 tnext=0x0 2006-09-25 16:48:12: DEBUG: 0x29423ff0: next=0x0 tnext=0x0 2006-09-25 16:48:12: DEBUG: prop#=1 prot-id=IPCOMP spi-size=4 #trns=1 trns#=1 trns-id=DEFLATE 2006-09-25 16:48:12: DEBUG: type=Encryption Mode, flag=0x8000, lorv=Tunnel 2006-09-25 16:48:12: DEBUG: type=SA Life Type, flag=0x8000, lorv=seconds 2006-09-25 16:48:12: DEBUG: type=SA Life Duration, flag=0x0000, lorv=4 2006-09-25 16:48:12: DEBUG: prop#=1 prot-id=ESP spi-size=4 #trns=1 trns#=1 trns-id=3DES 2006-09-25 16:48:12: DEBUG: type=Encryption Mode, flag=0x8000, lorv=Transport 2006-09-25 16:48:12: DEBUG: type=Authentication Algorithm, flag=0x8000, lorv=hmac-md5 2006-09-25 16:48:12: DEBUG: type=SA Life Type, flag=0x8000, lorv=seconds 2006-09-25 16:48:12: DEBUG: type=SA Life Duration, flag=0x0000, lorv=4 2006-09-25 16:48:12: DEBUG: peer's single bundle: 2006-09-25 16:48:12: DEBUG: (proto_id=IPCOMP spisize=4 spi=97e2b9ff spi_p=00000000 encmode=Tunnel reqid=0:0) 2006-09-25 16:48:12: DEBUG: (trns_id=DEFLATE) 2006-09-25 16:48:12: DEBUG: (proto_id=ESP spisize=4 spi=ffb9e297 spi_p=00000000 encmode=Transport reqid=0:0) 2006-09-25 16:48:12: DEBUG: (trns_id=3DES encklen=0 authtype=hmac-md5) 2006-09-25 16:48:12: DEBUG: my single bundle: 2006-09-25 16:48:12: DEBUG: (proto_id=IPCOMP spisize=4 spi=00000000 spi_p=97e2b9ff encmode=Tunnel reqid=1:1) 2006-09-25 16:48:12: DEBUG: (trns_id=DEFLATE) 2006-09-25 16:48:12: DEBUG: (proto_id=ESP spisize=4 spi=00000000 spi_p=ffb9e297 encmode=Transport reqid=2:2) 2006-09-25 16:48:12: DEBUG: (trns_id=3DES encklen=0 authtype=hmac-md5) 2006-09-25 16:48:12: DEBUG: matched 2006-09-25 16:48:12: DEBUG: === 2006-09-25 16:48:12: DEBUG: call pfkey_send_getspi 2006-09-25 16:48:12: DEBUG: pfkey GETSPI sent: IPCOMP/Tunnel 10.22.200.119[0]->10.22.200.1[0] 2006-09-25 16:48:12: DEBUG: call pfkey_send_getspi 2006-09-25 16:48:12: DEBUG: pfkey GETSPI sent: ESP/Transport 10.22.200.119[0]->10.22.200.1[0] 2006-09-25 16:48:12: DEBUG: pfkey getspi sent. 2006-09-25 16:48:12: DEBUG: pk_recv: retry[0] recv() 2006-09-25 16:48:12: DEBUG: get pfkey GETSPI message 2006-09-25 16:48:12: DEBUG: pfkey GETSPI succeeded: IPCOMP/Tunnel 10.22.200.119[0]->10.22.200.1[0] spi=19311(0x4b6f) 2006-09-25 16:48:12: DEBUG: pk_recv: retry[0] recv() 2006-09-25 16:48:12: DEBUG: get pfkey GETSPI message 2006-09-25 16:48:12: DEBUG: pfkey GETSPI succeeded: ESP/Transport 10.22.200.119[0]->10.22.200.1[0] spi=73617894(0x46351e6) 2006-09-25 16:48:12: DEBUG: total SA len=84 2006-09-25 16:48:12: DEBUG: Thanks again! -Matthew |
From: Matthew G. <mg...@sh...> - 2006-09-26 02:18:29
Attachments:
netmaskptr.diff
|
All, This fixes two out of bounds evaluations in ipsecdoi. They only go one byte past the buffer but I catch a signal when linked with electric fence. I should have looked at the code closer before copying the first instance into the second which was added recently. Anyhow, a small patch is attached. Thanks, -Matthew |
From: <ma...@ne...> - 2006-09-26 04:47:16
|
Matthew Grooms <mg...@sh...> wrote: > This fixes two out of bounds evaluations in ipsecdoi. They only go one > byte past the buffer but I catch a signal when linked with electric > fence. I should have looked at the code closer before copying the first > instance into the second which was added recently. Anyhow, a small patch > is attached. Committed. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: <ma...@ne...> - 2006-09-26 04:47:15
|
Matthew Grooms <mg...@sh...> wrote: > I have attached a version of your patch that cleanly applies to head. > There was a conflict with the 'generate_policy unique' changes. Maybe > Emmanuel can review this and get it committed. I did it (I meant commit it: reviewing it is beyond my knwoledge) -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: Jonathan A. K. <jak...@ko...> - 2006-10-17 21:08:34
|
On Mon, Sep 25, 2006 at 10:19:02PM +0200, Emmanuel Dreyfus wrote: > Matthew Grooms <mg...@sh...> wrote: >=20 > > Has anyone tried to use bundled SAs in head? Even after the doubl= e free > > bug was corrected, it doesn't appear to be working for me. >=20 > I never managed to get ESP+IPcomp working, despite intensive hacking. I > gave up with that feature. >=20 Hmm, that's odd, I've used it rather successfully, I think: http://jakllsch.kollasch.net/Blog/2006-04-16 This was on NetBSD 3.0 with KAME IPsec. Jonathan Kollasch |
From: <ma...@ne...> - 2006-10-17 21:15:22
|
Jonathan A. Kollasch <jak...@ko...> wrote: > Hmm, that's odd, I've used it rather successfully, I think: > http://jakllsch.kollasch.net/Blog/2006-04-16 > This was on NetBSD 3.0 with KAME IPsec. NetBSD 3.0 ships with ipsec-tools. Do you mean you installed the racoon from KAME as a replacement of NetBSD 3.0 built-in racoon (which is ipsec-tools version)? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: Jonathan A. K. <jak...@ko...> - 2006-10-17 22:25:58
|
On Tue, Oct 17, 2006 at 11:16:45PM +0200, Emmanuel Dreyfus wrote: > Jonathan A. Kollasch <jak...@ko...> wrote: >=20 > > Hmm, that's odd, I've used it rather successfully, I think: > > http://jakllsch.kollasch.net/Blog/2006-04-16 > > This was on NetBSD 3.0 with KAME IPsec. >=20 > NetBSD 3.0 ships with ipsec-tools. Do you mean you installed the racoon > from KAME as a replacement of NetBSD 3.0 built-in racoon (which is > ipsec-tools version)?=20 KAME IPsec as opposed to FAST_IPSEC, standard racoon from base. Also, a racoon built from a recent CVS checkout works too. Jonathan Kollasch |
From: Matthew G. <mg...@sh...> - 2006-10-17 21:54:22
|
Jonathan A. Kollasch wrote: > > Hmm, that's odd, I've used it rather successfully, I think: > http://jakllsch.kollasch.net/Blog/2006-04-16 > This was on NetBSD 3.0 with KAME IPsec. > > Jonathan Kollasch > It would appear that IPComp was known to be problematic in NetBSD for at least the FAST_IPSEC stack. A 2006 summer of code participant claims to have fixed transport mode for ipv4 while adding ipv6 support. http://www.netbsd.org/Foundation/press/soc2006-summary.html I hope these changes make their way into the other BSD's as well ( if not there already ). On my FreeBSD 6.1 gateway, FAST_IPSEC IPComp was disabled by default. I enabled it to perform some tests and ran into a kernel panic :( -Matthew |
From: <ma...@ne...> - 2006-10-18 05:23:28
|
Jonathan A. Kollasch <jak...@ko...> wrote: > Hmm, that's odd, I've used it rather successfully, I think: > http://jakllsch.kollasch.net/Blog/2006-04-16 > This was on NetBSD 3.0 with KAME IPsec. Ok, I now understand: I failed to have it working for Cisco vs NetBSD. I never tried NetBSD vs NetBSD. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: Brian C. <B.C...@po...> - 2006-09-26 05:35:42
|
On Mon, Sep 25, 2006 at 02:47:32PM -0500, Matthew Grooms wrote: > 1) Encrypt the packet using ESP ( transport, no new ip header ) > 2) Compress the packet using IPCOMP ( tunnel, add new ip header ) > > I want this order as IPCOMP says that you need to do compression after > encryption. That doesn't make any sense; any packet which has been encrypted will be uncompressible. See RFC 3173, which says: "If both compression and encryption are required,compression must be applied before encryption." |
From: Matthew G. <mg...@sh...> - 2006-09-26 06:51:16
|
Brian Candler wrote: > On Mon, Sep 25, 2006 at 02:47:32PM -0500, Matthew Grooms wrote: >> 1) Encrypt the packet using ESP ( transport, no new ip header ) >> 2) Compress the packet using IPCOMP ( tunnel, add new ip header ) >> >> I want this order as IPCOMP says that you need to do compression after >> encryption. > > That doesn't make any sense; any packet which has been encrypted will be > uncompressible. > > See RFC 3173, which says: "If both compression and encryption are > required,compression must be applied before encryption." > |
From: Matthew G. <mg...@sh...> - 2006-09-26 07:34:48
|
Brian Candler wrote: > On Mon, Sep 25, 2006 at 02:47:32PM -0500, Matthew Grooms wrote: >> 1) Encrypt the packet using ESP ( transport, no new ip header ) >> 2) Compress the packet using IPCOMP ( tunnel, add new ip header ) >> >> I want this order as IPCOMP says that you need to do compression after >> encryption. > > That doesn't make any sense; any packet which has been encrypted will be > uncompressible. > > See RFC 3173, which says: "If both compression and encryption are > required,compression must be applied before encryption." > Brian, Absolutely, your right. I have no idea how I wrote that down so perfectly backwards. Thanks for pointing this out. Have you had any luck getting IPCOM and ESP to work? I'm still left scratching my head. The bundled SA's can be established with keys installed but when the IPSEC processing happens I don't get output like I would expect. It could easily be a matter of me not observing things correctly, but the closest I get is when I specify it backwards ( as erroneously described above ). This shows the packet being processed by both transforms in SAD with the result being an IPCOMP packet instead of an ESP packet. If I specify it the other way around ( like I meant and as you suggested ), only the ESP transform shows that it has processed the packet in SAD. I probably need to go back and do some more testing and then bring it up on the FreeBSD net list. Thanks, -Matthew |