Hello,
I'm the developer behind the MPLS for Linux project. As part of my
development I've added some fields to skbs and fib_node. Maybe the scheme
I've used can be extended for this purpose.
I've added a field to skbs called aux_protodata. Its an array of void*.
Auxiliary protocols (one that don't fit the normal Linux network stack
model) can mark interest in a particular protocol and store data here
for later use. For example, MPLS uses this by coping data from fib_nodes
into this field in the skb, at the same time it creates a dst_entry that
redirect the skb to an mpls_output function. There the aux_protodata is
used to find the next hop label forwarding entry needed to transmit this
packet on a label switched path.
The short coming of this model so far is that it should use a netfilter like
scheme for redirecting packets at certain points in the network stack.
Why not use netfilter? The places that auxiliary protocols need to
modify skbs or dst_entries are different then those provided by netfilter.
Plus there should be a clear difference between what is being accomplished
via netfilter (IPvX packet redirecting/mangling) and aux_protodata (protocol
agnostic redirecting/mangling). If people think netfilter can be modified
to support the needs of auxiliary protocol, and this fit the original intent
for netfilter, I'd be more then happy to extend it to fit the needs of MPLS
and IPSEC.
Just my $.02
Jim
On Thu, Oct 25, 2001 at 02:41:22PM -0400, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> {netdev folks.
> This is a continuation of a thread started until the title:
> Re: [Design] reg: encryption of MPLS pkts using IPSEC
> at: http://lists.freeswan.org/pipermail/design/2001-October/001014.html
>
> This has prodded me to post this message, which I've been meaning to do.}
>
> >>>>> "Sandeep" == Sandeep Subramaniam <sandeeps@xxxxxxxxxxx> writes:
> Sandeep> I actually want the MPLS pkts created by me to be encrypted by
> IPSEC
> Sandeep> transport mode .
>
> Sandeep> Assume that I have already created the MPLS pkt in a skb
> structure
>
> Aha, RGB! a customer for the skb->{security,ipcb,fwmark} mechanism. Well
> maybe.
>
> The direction that we are going is to have the FreeSWAN xmit code look at a
> member in the skb that picks the appropriate SA (chain). The issue is which
> field to
> use. Criteria are:
>
> 1) should be present in all kernels.
> 2) must not be a "crypto-shaped-hole" (if it is a designated field, it
> must be multipurpose)
> 3) must be at least 16-bits in size.
> 4) must be settable via netfilter and/or advanced routing.
>
> There are several fields that might be used:
> skb->security (16-bit)
> skb->nfmark (much contention for this field)
> skb->cb (see linux/ip.h, and net/ip.h's IPCB macro)
>
> skb->priority is currently used by QoS mechanisms. We want precisely the
> same kind of thing.
>
> skb->security seems to have been added to support the NRL code. It is
> copied in one place (ip_output.c) and zeroed in (skbuff.c), which is about
> it. We would need to add netfilter support for setting it and testing it.
> And there is linux/ipsec.h. Seems a bit odd for this to be there.
> Criteria #2 makes us nervous about using skb->security.
>
> Re: criteria #3. People who need more than 64K security associations can
> probably cope with recompiling their kernel. We are concerned about people
> who have generic kernels with no built-in crypto who want to do basic stuff.
>
> skb->cb is relatively easy to extend, and would require no changes to a
> base kernel.
>
> We can load the load/set code into Netfilter, so this is somewhat a neutral
> decision.
>
> We are seeking opinions.
>
> ] ON HUMILITY: to err is human. To moo, bovine. | firewalls
> [
> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net
> architect[
> ] mcr@xxxxxxxxxxxxxxxxxxxxxx http://www.sandelman.ottawa.on.ca/ |device
> driver[
> ] panic("Just another NetBSD/notebook using, kernel hacking, security guy");
> [
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: latin1
> Comment: Finger me for keys
>
> iQCVAwUBO9hc0IqHRg3pndX9AQGoMQP7BNEMBIEsCO0ePQvULc2rDxVKghhtMKQP
> v516KLWwqhl5/isTnVgLCAWgHSZmeVRatTY408gMEOU3PYENJGgqReZUDMSZieUn
> a2wyJD81tCfX/RD8CFFKR8Tov1tbCpXNMy/EuKzhB9e/ExqVWtMJw0RqrfQDOkux
> JVMqmQs2VWY=
> =z0ez
> -----END PGP SIGNATURE-----
--
James R. Leu
|