Am Montag, 10. Mai 2004 08:49 schrieb Nico Schottelius: > Good morning, > > Gregor Paasch [Mon, May 10, 2004 at 12:22:21AM +0200]: > > > [solved the issue with marking] > > > > Many many thanks for this hint. I was searching the web so long for an > > acceptable solution for this problem. I have just tried out your > > solution and it works great. > > Well, it's very nice that there is at least an workaround > for it. I will try the hints from the netfilter list the next > days and report whether something changed or not. > > I'll also contact the ipsec people (KAME, iirc) in the next days to ask > them for their opinion to that problem. > > The way Wolfang described and Gregor used works, but is imho > very ugly. > > Nico Yes, it would be good if netfilter would be enhanced so that there is a native check for "came in as ipsec". I don't think it would be a good idea though the have some sort of tunnel devices. Well, actually ipsec itself is very ugly. I do not want to say that the implementation in the linux 2.6. kernel is ugly: it is a rather good decision not to have extra tunnel devices, i.e.: it garanties its orthogonality to routing, source-adress selections, netfilter etc. The problems with ipsec and netfilter is more that netfilter is sometimes a little bit barock and itself rather bad documented (especially missing is a clear description how exactly packets flow through the whole system). For ipsec, in contrast, its rather clear: look at the SPD and you know which pakets will be encrypted, not encrypted, decrypted or forbidden. How you exactly route the packets i.e. does not matter, nor which interfaces you have etc. With ugly I mean: IPSec itself is not well understood because it is complex and bad documented. When you search the internet or read books about IPSec: all vague and often wrong. Rather understanable: I read the related RFCs and I think they are terrible documents. They not even try to define what IPSec should do: what security service it should exactly provide. Compare that with the RFCs for TCP, i.e.: clear agenda: Basic Data Transfer, Reliability, Flow Control, Multiplexing, Connections, Precedence and Security. It follows a more exact what the authors mean with those. User don't have to understand the internals of the protocol to understand if TCP is for them or not. People reviewing the protocol know what to check: does the protocol have these properties. Whatever "knobs" TCP has, you know: they may chance performance but these fundamental properties remain. Know look at ipsec: its only a description of a family of protocols with many (interdepended) "knobs". No clear concrete security goals are given in the form "set these knobs like that and then ipsec should provide the following security properties". They declare that IPSec should be a help for the household. They do not say if it is a vacuum cleaner, a toaster or a dishwasher or all at once. You study the constructions plans and descriptions, then some books about machine and constrcution, and conclude that its probably a dishwasher which can be also used as washing machine with tens of different washing-programs (which often do the same). You have to be very carefull though because it may destroy your clothes completely without your deep understanding how the machine internaly works. Because there is no knob 40 degrees or so but you have to set 23 resistors to there correct value. Which restores and to what values: well, you have the description how the machine works. Interestingly it may be abused as a toaster. Ok, this was a little bit polemic. And as I sad it is complex. So implementations will contain a lot of bugs. When we tested racoon with "nonsense" input over the net or a "not well behaved partner" it often crashed with segfault (same with isakmpd). We detected that racoon even didn't correctly check certificates (many thanks to Ralf Spenneberg for looking into the code and providing a fix for that). So even if you have a very deep understanding of IPSec and crypthografic protocols to set all knobs so that you get the security properties you need you probably will fail because your ipsec-implementation get hacked. Under this light I think the need to mark ipsec-pakets in netfilter to destinquish them from non-ip-sec-traffic is a rather secondary thing. Some lines in a how-to. -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts EDV - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
