Date: Wed, 02 May 2001 09:40:28 +0900 From: itojun@iijlab.net To: snap-users@kame.net Cc: freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au, altq@csl.sony.co.jp Subject: Re: (KAME-snap 4593) Re: The future of ALTQ, IPsec & IPFILTER playing together ... Message-ID: <5342.988764028@itojun.org> In-Reply-To: gunther's message of Tue, 01 May 2001 18:45:38 GMT. <3AEF0452.C2FD2651@aurora.regenstrief.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>WAY A: CONTINUE TIGHT KERNEL-COUPLING > >- KAME IPsec, ALTQ and IPfilter's rules engine to be combined > into one classifier. > >- IPFILTER ---> IPSEC ---> ALTQ to be placed in this order of > processing (on outgoing packets) > >- IPSEC to make sure the packet labels attached by the classifier > are available for ALTQ even after encapsulation. the problem is not this simple. if the problem is this simple, we should have solved this already and KAME would have been disbanded :-) i guess you are looking at originating case (packets generated by the router itself). however, there are other items you need to look at. try to think about outbound path too, and forwarding path. ipfilter, IPsec and ALTQ wants to filter at different point in the code path, and they would like to look at different portions. for originating case your way (look at packets before encapsulation) makes sense for your particular example. however, - when people who use ipfilter/ipsec/ipnat/altq for different purposes, they want a different ordering of events. for example, there are people who want to filter packets after IPsec encapsulation. - another example, i guess the order won't work if you run ipnat (NAT portion of ipfilter). this is a hard problem, and I guess I can never solve it perfectly. IMHO, all the mess came from the very concept of tunnelling, private address reuse (NAT), and other things. i like diffserv, but i would like to see it without NAT nor tunnelling. maybe this is one of the reasons I'm more into IPv6, IPsec transport mode, and the world without tunnelling... :-) if you have various commercial vendor routers, please try to decipher what they are doing internally about it, from the manuals. maybe it gives you a good hint (or bad hint). itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5342.988764028>