| |||||||||||||
Van Jacobson's network channelsVan Jacobson's network channelsPosted Jan 31, 2006 22:02 UTC (Tue) by ernest (subscriber, #2355)Parent article: Van Jacobson's network channels
Interesting, but where do things like iptable and other network security
(Log in to post comments)
Van Jacobson's network channels and Netfilter Posted Jan 31, 2006 22:29 UTC (Tue) by csamuel (✭ supporter ✭, #2624) [Link] I was fortunate enough to be both at the original presentation and when he repeated it for the "best of" stream at the end of LCA2006 and got to ask him about what the situation was with netfilter.
His comment was that there was no reason why netfilter couldn't become just another consumer of packets, and my take on that is that whilst that would require patching to the netfilter code that too could be a good thing if it eliminates the use of double-linked lists (the use of which would cause you to fail CS 101 under VJ according to him :-)) but would probably be a lot of code.
Of course this is only necessary if you go further than chanellising the drivers themselves as one of the really elegant things is that this change of thinking is that its very modular - you can convert drivers one at a time until they're all done, then start on looking at channelising the socket layer and then start on the consumers of the socket layer.
There are 2 nice things about having the TCP stack running in user space, one is that it allows you to easily experiment and debug TCP issues and have custom behaviour for different applications based on need, and the second is that VJ explained the only reason it had to go into the kernel in Multics in the first place was that if a user process got pages out there it could take 2 minutes to get paged in, which TCP/IP doesn't like.. :-)
Chris
Van Jacobson's network channels Posted Feb 1, 2006 11:00 UTC (Wed) by james (subscriber, #1325) [Link] Presumably you can do a lot of security when you set up the channels. It looks like the packet classifier:reads the protocol, ports, and addresses to determine the flow ID and uses this to find a channel(Dave Miller's blog). That looks like it's enough for most firewalling: it should give you pass (existing channel), fail (no channel), or needs more work (channel to netfilter).
Van Jacobson's network channels Posted Feb 1, 2006 20:00 UTC (Wed) by NAR (subscriber, #1313) [Link] I'm not sure I fully understand this, but it seems that these channels are used when there is a socket to the user space, i.e. an application running on the host sends/receives data to/from the network. But what about the case when there's no application? As far as I know, in routers the IP packets usually don't get to user space, but if protocol processing is moved to user space (netfilter), it might degrade performance, mightn't it?
Van Jacobson's network channels Posted Feb 2, 2006 5:45 UTC (Thu) by xoddam (subscriber, #2322) [Link] The phased implementation described only moves packet processing touserspace at the very last stage. At the 'ends' of the network this is appropriate for efficiency. But even before that stage, channels are a better way to pass packets around within the kernel. The task-oriented interface (using wakeups instead of soft interrupts) would probably mean netfilter no longer runs in tasklet context. We might instead see several netfilter kernelspace daemons (like kswapd and friends), one for each CPU.
Van Jacobson's network channels Posted Feb 2, 2006 9:57 UTC (Thu) by NAR (subscriber, #1313) [Link] Wouldn't it lead to code duplication? For example, a box doing NAT would need a (limited?) TCP/IP implementation in kernel space, while the host running e.g. an FTP client would need the full TCP/IP implementation in user space.
Van Jacobson's network channels Posted Feb 2, 2006 23:56 UTC (Thu) by xoddam (subscriber, #2322) [Link] > Wouldn't it lead to code duplication?Yes. So does inlining :-)
Van Jacobson's network channels Posted Feb 2, 2006 21:46 UTC (Thu) by iabervon (subscriber, #722) [Link] I don't see any reason that all of the channels would have to go to userspace. If a packet is to a kernel NFS client, it would end up in the kernel code, but without all the copies between the network and the VFS.
Of course, the kernel would have to keep a TCP implementation, but that's not surprising, since static binaries that use sockets should continue to work.
Van Jacobson's network channels Posted Feb 2, 2006 12:29 UTC (Thu) by samj (subscriber, #7135) [Link] If it doesn't cost anything, why not? You'd just plug netfilter in before the app and map packet buffers into its address space first. This can all be done in a separate security context too. Looks to me like it would mean a lot less in the way of protocol specific handling and would allow you to chain such tasks easily (eg netfilter->ipsec or netfilter->reverse proxy->web server etc.).
Van Jacobson's network channels Posted Feb 2, 2006 20:12 UTC (Thu) by jonabbey (subscriber, #2736) [Link] Please, someone tell me they're not re-inventing STREAMS.
Van Jacobson's network channels Posted Feb 2, 2006 20:53 UTC (Thu) by caitlinbestler (guest, #32532) [Link] Connections can be channelized *after* they havepassed netfilter inspection.
|
|||||||||||||