RE: State of play with Shim6 documents

["Henderson, Thomas R" <thomas.r.henderson@boeing.com>]

> -----Original Message-----
> From: Erik Nordmark [mailto:erik.nordmark@sun.com] 
> Sent: Tuesday, March 13, 2007 2:21 PM
> To: Henderson, Thomas R
> Cc: Geoff Huston; shim6-wg; kurtis@kurtis.pp.se
> Subject: Re: State of play with Shim6 documents
> 
> Henderson, Thomas R wrote:
> 
> > For the data plane, I understand your point that it may be 
> moot if the
> > control plane were to be supported without modifications, 
> if the data
> > plane could not be.  However, I was thinking that judicious 
> use of Linux
> > netfilter could be used to insert the data plane shim.  In 
> particular,
> > the IP6 local in and local out hooks seem well positioned 
> in the stack
> > to support a shim6 shimming module.
> 
> If you do that, then you could use the same hook for all the shim6 
> messages, right?
> 
> > My basic concern is that it would be nice to support shim6 without
> > patching the Linux kernel, for deployment/experimental 
> purposes.  It may
> > be possible to make this work as defined now without a 
> patched kernel.
> > I think it may require some more complicated matching rules 
> to divert
> > shim6 control packets to user space while diverting shim6 
> data packets
> > to a deshimming module, and making sure there is some way 
> to inject the
> > control plane packets from user space.  I suspect it will 
> be harder to
> > do the way it is defined, including for non-Linux systems, 
> but perhaps
> > not impossible.
> 
> There is a single bit in the shim6 header which says whether it is a 
> payload message or something else. So it shouldn't be hard to have 
> different rules.
> 
> > Since I understand the motivation you have here, I think it would be
> > best to avoid speculating and experiment with the above to 
> see if it can
> > work.  I'll try to get some results in the next week or two 
> and report
> > back.
> 

Erik,
It looks like we are able to achieve our objective of developing an
experimental shim6 implementation in Linux, with a user-space control
plane and kernel-based shimming, without patching the Linux kernel:
- shim6 control messages can be written out from user-space over IPv6
raw sockets
- shim6 control messages can be filtered and written to user-space
through a combination of ip6tables and libnetfilter_queue; the filtering
granularity can look at the shim6 P-bit
- shim6 data plane (the per-packet shim header) can be inserted and
removed via an ip6tables mangle rule (directed to a loadable kernel
module and controlled via netfilter)
- nf_conntrack can be used for connection tracking (to invoke the shim
after a certain number of packets)

The above pertains to Linux only; I haven't considered solutions for
other platforms.  Of course, on most platforms one can route all packets
through userspace where they can be filtered/touched, but there is a
performance hit when doing that.  But I don't think that having shim6 on
two protocol numbers will help that issue much anyway.

In conclusion, I don't think that it will make that big a difference
after all whether there are one or two protocol numbers, so it seems
like the firewall considerations lean towards keeping things the way
they are now.

-Tom