netdev
[Top] [All Lists]

skb->security and friends

To: design@xxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
Subject: skb->security and friends
From: Michael Richardson <mcr@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 25 Oct 2001 14:41:22 -0400
In-reply-to: Your message of "Thu, 25 Oct 2001 01:09:50 CDT." <Pine.LNX.4.10.10110250102070.12619-100000@astro.ittc.ku.edu>
Sender: owner-netdev@xxxxxxxxxxx
-----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-----

<Prev in Thread] Current Thread [Next in Thread>