[PATCH] USAGI IPsec

[PATCH] USAGI IPsec

[Mitsuru KANDA]

Hello Linux kernel network maintainers,

I'm a member of USAGI project.

In IPv6 specifications, IPsec is mandatory.

We implemented IPsec for Linux IP stack.

At present, our implementation includes:
	PF_KEY V2 interface,
	Security Association Database and
	Security Policy Database for whole IP versions,
	IPsec for IPv6,(transport, tunnel mode),
	IPsec for IPv4 (transport mode),

Would you mind checking it ?

The patch is a little too big to send to the mailing list.

Please visit our ftp site <ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/>
and retrieve it from 
    ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/ipsec-2.5.41-ALL.patch.gz
    ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/ipsec-2.4.20-pre10-ALL.patch.gz
    (more patches are available)

Regards,
-mk

=== For more details ===
##### USAGI IPsec #####

Table of Contents
	1. How to Apply Patches
	2. Cipher/Digest Algorithms
	3. PF_KEY v2 Implementation
	4. IPsec Implementation
	4.1 Supported Header Order
	4.2 IPsec Mode
	4.3 Packet Processing
	4.4 Conformance Test
	5. New and Changed Files
	6. References
	7. Acknowledgements
--------------------------
1. How to Apply Patches

	1. apply CryptoAPI patch (if you need to compile for test)
	2. apply ipsec-2.4.20-pre10-ALL.patch.gz 
	   or ipsec-2.5.41-ALL.patch.gz

	We also prepared rough split patches.
        (for PF_KEY, IPv6 and IPv4 part)
	If you apply them instead of ipsec-*-ALL.patch.gz,
	please apply following order:
		ipsec-2.4.20-pre10-PFKEY.patch.gz
		ipsec-2.4.20-pre10-IPV6.patch.gz
		ipsec-2.4.20-pre10-IPV4.patch.gz
	(sorry we haven't prepared rough split patches for 2.5)


2. Cipher/Digest Algorithms

	Supported algorithms:
		Ciphers: DES, 3DES and AES
		Digests: MD5 and SHA1

	We use CryptoAPI as cipher/digest algorithm.
	- CryptoAPI
		http://www.kerneli.org/

3. PF_KEY v2 Implementation

	We introduced struct sockaddr_storage{} to handle both IPv4 and
	IPv6 in Security Association Database (SADB) and Security
	Policy Database (SPD).

	We conform to RFC2367 (PF_KEY_V2).
	Many other implementations have extended PF_KEY_V2 protocol to
	process IPsec Security Policy. We have implemented FreeS/WAN's
	PF_KEY extension in order to be compatible with their
	IKEv1 daemon (Pluto).

4. IPsec Implementation

	RFC 2401  Security Architecture for IP
	RFC 2402  IP Authentication Header
	RFC 2406  IP Encapsulating Security Payload

4.1 Supported Header Order

	We support [AH], [ESP], and [AH][ESP].

4.2 IPsec Mode

	Transport Mode

		IPv[46]:
		 We implemented inside IP stack.

	Tunnel Mode
		We implemented  IPsec Tunnel Mode by making use of IP
		over IP tunnel 

		IPv6:
		 We realized it by making use of HUT(mipl) IPv6 over
		 IPv6 tunnel.

		IPv4:
		 Not yet implemented.(Do we use net/ipv4/ipip.c ?)

4.3 Packet Processing

	Inbound Processing

	Our implementation parses AH and ESP in extension header
	parsing routine	(ipv6_parse_exthdrs()). The kernel
	parses AH and ESP and keeps the information of SAs which are
	used during the processing in skb->cb as struct	inet6_skb_parm{}.
	The kernel keeps the AH SA information as offset from a IPv6
	header 	(the kernel doesn't remove AH header). 
	It also keeps ESP SA information as SPI value.

	If there is something wrong in processing AH and/or ESP, the
	kernel drops the packet. When processing completes successfully,
	the kernel compares SAs information and policy in
	ipsec6_input_check(), which is called from ip6_input_finish().

	When using tunnel mode, there are a couple of differences from
	transport mode.	The AH and ESP parsing is same as transport
	mode. However, in tunnel mode the kernel uses the inner header's
	addresses as key to lookup IPsec Security Policy Database.

	Outbound Processing

	The kernel checks IPsec Security Policy Database using as a key
	the src/dst address pair. If it matches with the action applying
	IPsec, start IPsec processing (preparing AH calculation, ESP
	encryption, AH calculation).

4.4 Conformance Test

	We have tested TAHI <http://www.tahi.org/> conformance test.
	The results are fine.

5. New and Changed Files

net/key:
Config.in		(NEW) - 
Makefile		(NEW) - 
af_key.c		(NEW) - PF_KEY_V2 socket interface 
                                (derived from FreeS/WAN 1.9
                                 pfkey_v2.c. changed a lot.)
pfkey_v2_build.c	(NEW) - building PF_KEY message 
                                (derived from FreeS/WAN 1.9
                                 changed a little.)
pfkey_v2_ext_bits.c	(NEW) - (derived from FreeS/WAN 1.9. 
                                 changed a little.)
pfkey_v2_msg.c		(NEW) - PF_KEY helper functions(SA lifetime,...)
pfkey_v2_msg.h		(NEW) - header file for pfkey_v2_msg.c
pfkey_v2_msg_add.c	(NEW) - processing SADB_ADD message 
pfkey_v2_msg_delete.c	(NEW) - processing SADB_DELETE message
pfkey_v2_msg_flow.c	(NEW) - processing SADB_X_ADDFLOW 
                                and SADB_X_DELFLOW messages
pfkey_v2_msg_get.c	(NEW) - processing SADB_GET message
pfkey_v2_msg_getspi.c	(NEW) - processing SADB_GETSPI message
pfkey_v2_msg_update.c	(NEW) - processing SADB_UPDATE message
sa_index.c		(NEW) - Security Association (SA) index 
                                (handle struct sa_index{})
sadb.c			(NEW) - SA Database
sockaddr_utils.c	(NEW) - utilities
sockaddr_utils.h	(NEW) - utilities
spd.c			(NEW) - Security Policy (SP) Database
sysctl_net_ipsec.c	(NEW) - sysctls (replay window and debug switch.)

net/ipv6:
Config.in		(CHANGED)
Makefile		(CHANGED)
exthdrs.c		(CHANGED) - inserted ipsec processing functions
ip6_input.c		(CHANGED) - inserted ipsec processing functions
ip6_output.c		(CHANGED) - inserted ipsec processing functions
ipsec6_input.c		(NEW)	  - IPsec processing for input packet
ipsec6_output.c		(NEW)     - IPsec processing for output packet
ipv6_sockglue.c		(CHANGED) - inserted IPsec processing functions.
ndisc.c			(CHANGED) - inserted ipsec processing functions
                                    (for ND packets)
reassembly.c		(CHANGED) - inserted IPsec processing functions.
tcp_ipv6.c		(CHANGED) - inserted IPsec processing functions. 
                                    (based IABG IPv6 implementation)
net/ipv4:
Config.in		(CHANGED) -
Makefile		(CHANGED) - 
ip_input.c		(CHANGED) - inserted ipsec processing functions
ip_output.c		(CHANGED) - inserted ipsec processing functions
ipsec4_input.c		(NEW)     - IPsec processing for input packet
ipsec4_output.c		(NEW)     - IPsec processing for output packet
tcp_ipv4.c		(CHANGED) - inserted ipsec processing functions

include/linux:
ip.h			(CHANGED) - introduced struct ip_auth_hdr{} 
                                    and ip_esp_hdr{}.
ipsec.h			(CHANGED) - added IPsec actions and 
                                    IPsec4 processing functions.
ipsec6.h		(NEW)     - added IPsec6 processing functions.
pfkey.h			(NEW)     - PF_KEY related structs 
                                    (derived from FreeS/WAN 1.9)
pfkeyv2.h		(NEW)     - PF_KEY_V2 header file
ipv6.h			(CHANGED) - introduced struct ipv6_auth_hdr{} 
                                    and ipv6_esp_hdr.
                                    added  'espspi' member 
                                    in struct inet6_skb_parm.
socket.h		(CHANGED) - introduced struct sockaddr_storage{} 
                                    to handle both IPv4 and IPv6
                                    sockaddr in SADB/SPD.
sysctl.h		(CHANGED) - added IPsec entry.

include/net:
sadb.h			(NEW)     - SA Database header file
spd.h			(NEW)     - SP Database header file
ipv6.h			(CHANGED) - changed ipv6_parse_exthdrs()

6. References

	USAGI Project http://www.linux-ipv6.org/
	CryptoAPI http://www.kerneli.org/
	FreeS/WAN http://www.freeswan.org/
	IABG http://www.ipv6.iabg.de/

7. Acknowledgements

	Joy Latten <latten@austin.ibm.com>
	and IBM IPv6 team

Re: [Design] [PATCH] USAGI IPsec

[David S. Miller]

   From: Sandy Harris <sandy@storm.ca>
   Date: Sat, 12 Oct 2002 10:11:07 -0700

   Please remove DES as it is insecure. For discussion, see:
   http://www.freeswan.org/freeswan_trees/freeswan-1.98b/doc/politics.html#desnotsecure

It's fine for testing purposes, leave it in.

Re: [Design] [PATCH] USAGI IPsec

[Sandy Harris]

Mitsuru KANDA wrote:

>Hello Linux kernel network maintainers,
>
>I'm a member of USAGI project.
>  
>
   [snip]

>2. Cipher/Digest Algorithms
>
>	Supported algorithms:
>		Ciphers: DES, 3DES and AES
>		Digests: MD5 and SHA1
>
>	We use CryptoAPI as cipher/digest algorithm.
>	- CryptoAPI
>		http://www.kerneli.org/
>  
>
Please remove DES as it is insecure. For discussion, see:
http://www.freeswan.org/freeswan_trees/freeswan-1.98b/doc/politics.html#desnotsecure

Re: [Design] [PATCH] USAGI IPsec

[Zach Brown]

> It's fine for testing purposes, leave it in.

absolutely.  it could also be needed for interoperability, or many other
valid uses that might not depend on its sheer strength as a cipher.

"but you shouldn't be interoperating with things that are insecure!"

blah blah blah.  that is not the kernel's decision to make.  meaningful
security is defined by much more than context-free assertions.  warn
against its naive use, avoid it being a default, but allow the clued to
use it easily when it makes sense.

- z

Re: [Design] [PATCH] USAGI IPsec

[David S. Miller]

> Is this code being checked in to the mainline kernel? Or becoming part 
> of the
> CryptoAPI patch set? Bravo, in either case.

We will be incorporating lots of ideas and small code pieces
from USAGI's work, but most of the core engine will be a new
implementation.

A completely new CryptoAPI subsystem has been implemented so that
full lists of page vectors can be passed into the ciphers, which is
necessary for a clean IPSEC implementation.

It is intended that this work will be complete (it isn't done as I
type this) and pushed to Linus upon his return from vacation.

Re: [Design] [PATCH] USAGI IPsec

[YOSHIFUJI Hideaki / 吉藤英明]

In article <1035168066.4817.1.camel@rth.ninka.net> (at 20 Oct 2002 19:41:06 -0700), "David S. Miller" <davem@rth.ninka.net> says:

> > Is this code being checked in to the mainline kernel? Or becoming part 
> > of the
> > CryptoAPI patch set? Bravo, in either case.
> 
> We will be incorporating lots of ideas and small code pieces
> from USAGI's work, but most of the core engine will be a new
> implementation.
:
> It is intended that this work will be complete (it isn't done as I
> type this) and pushed to Linus upon his return from vacation.

Well, we'd like to learn more about your ideas...
Source code is our friend.
If you don't mind, would you send "as-is" codes to us?

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: [Design] [PATCH] USAGI IPsec

[Andre Hedrick]

It is all bolted togather and does not need to be piece from random parts.
Thus in simple reality, it is superior.

Maybe FreeS/WAN will get busy and compete or die.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Mon, 21 Oct 2002, Sandy Harris wrote:

> Mitsuru KANDA wrote:
> 
> >Hello Linux kernel network maintainers,
> >
> >I'm a member of USAGI project.
> >
> >In IPv6 specifications, IPsec is mandatory.
> >
> >We implemented IPsec for Linux IP stack.
> >
> >At present, our implementation includes:
> >	PF_KEY V2 interface,
> >	Security Association Database and
> >	Security Policy Database for whole IP versions,
> >	IPsec for IPv6,(transport, tunnel mode),
> >	IPsec for IPv4 (transport mode),
> >
> >Would you mind checking it ?
> >
> Is this code being checked in to the mainline kernel? Or becoming part 
> of the
> CryptoAPI patch set? Bravo, in either case.
> 
> How does that affect FreeS/WAN development?
> 
> >  
> >
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec

[Herbert Valerio Riedel]

On Mon, 2002-10-21 at 04:41, David S. Miller wrote:

> A completely new CryptoAPI subsystem has been implemented so that
> full lists of page vectors can be passed into the ciphers, which is
> necessary for a clean IPSEC implementation.

oh... nice to learn about your plans (so late) at all ;-)

well, it would be cool if you'd cooperate (or at least share
information) with us (the official cryptoapi project ;-), as we're open
for the design requirements of the next generation cryptoapi...

...otherwise this may render the kerneli.org/cryptoapi effort completely
useless :-/ ...of course, if it's your long term goal to take the
cryptoapi development away from kerneli.org, I'd like to know too ;-)

regards,
-- 
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hvr@hvrlab.org       /    Finger hvr@gnu.org for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F
4142

Re: [Design] [PATCH] USAGI IPsec

[Sandy Harris]

Mitsuru KANDA wrote:

>Hello Linux kernel network maintainers,
>
>I'm a member of USAGI project.
>
>In IPv6 specifications, IPsec is mandatory.
>
>We implemented IPsec for Linux IP stack.
>
>At present, our implementation includes:
>	PF_KEY V2 interface,
>	Security Association Database and
>	Security Policy Database for whole IP versions,
>	IPsec for IPv6,(transport, tunnel mode),
>	IPsec for IPv4 (transport mode),
>
>Would you mind checking it ?
>
Is this code being checked in to the mainline kernel? Or becoming part 
of the
CryptoAPI patch set? Bravo, in either case.

How does that affect FreeS/WAN development?

>  
>

Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec

[Sandy Harris]

Herbert Valerio Riedel wrote:

>On Mon, 2002-10-21 at 04:41, David S. Miller wrote:
>
>  
>
>>A completely new CryptoAPI subsystem has been implemented so that
>>full lists of page vectors can be passed into the ciphers, which is
>>necessary for a clean IPSEC implementation.
>>    
>>
>
>oh... nice to learn about your plans (so late) at all ;-)
>
>well, it would be cool if you'd cooperate (or at least share
>information) with us (the official cryptoapi project ;-), as we're open
>for the design requirements of the next generation cryptoapi...
>
>...otherwise this may render the kerneli.org/cryptoapi effort completely
>useless :-/ ...of course, if it's your long term goal to take the
>cryptoapi development away from kerneli.org, I'd like to know too ;-)
>
>regards,
>  
>
I think the long term goal should be to get good crypto, at least IPsec 
and disk encryption,
into the mainline, standard Linux kernel. Also ipv6 support. Projects 
like FreeS/WAN, USAGI
and cryptoapi seem necessary for getting the work done in the first 
place, but eventually you
want to do away with patch sets and just have all the good stuff built 
in to the kernel.

One payoff is integration. As I understand it, a current fully-patched 
kernel has either MD-5
or SHA-1 in the /dev/random driver, both in FreeS/WAN, and possibly both 
of those plus a
few other hashes in the CryptoAPI stuff. This is silly. The obvious fix 
is for everyone to use
the CryptoAPI hashes and ciphers.

However, crypto is a special case. The US government (among others) has 
a long history
of  restricting it and, much as we would like to see good crypto in the 
standard kernel,
there's a good case for being very careful to keep code out of their 
clutches.

My suggestion would be that the standard kernel incorporate only one 
good hash
and one good cipher, specifically AES and SHA-256 since (last I looked) 
those
were en route to becoming requirements for IPsec. Let the FreeS/WAN and
CryptoAPI folk -- outside the US -- maintain the other ciphers and 
hashes. That
way we have a fallback position if the US goes back to being viciously 
restrictive.

Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec

[Jari Ruusu]

Herbert Valerio Riedel wrote:
> On Mon, 2002-10-21 at 04:41, David S. Miller wrote:
> > A completely new CryptoAPI subsystem has been implemented so that
> > full lists of page vectors can be passed into the ciphers, which is
> > necessary for a clean IPSEC implementation.
> 
> oh... nice to learn about your plans (so late) at all ;-)
> 
> well, it would be cool if you'd cooperate (or at least share
> information) with us (the official cryptoapi project ;-), as we're open
> for the design requirements of the next generation cryptoapi...

Official cryptoapi? Define official.

> ...otherwise this may render the kerneli.org/cryptoapi effort completely
> useless :-/ ...of course, if it's your long term goal to take the
> cryptoapi development away from kerneli.org, I'd like to know too ;-)

kerneli.org/cryptoapi _is_ useless joke for many needs. Fortunately other
people are able to see the limitations/sillyness of kerneli.org/cryptoapi:

1)  You are trying to replace link/insmod time overhead with runtime
    overhead + unnecessary bloat.
2)  No direct link access to low level cipher functions or higher level
    functions.
3)  No clean way to replace cipher code with processor type optimized
    assembler implementations.

Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>

Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec

[Jean-Luc Cooke]

On Tue, Oct 22, 2002 at 08:02:00AM +0300, Jari Ruusu wrote:
> kerneli.org/cryptoapi _is_ useless joke for many needs. Fortunately other
> people are able to see the limitations/sillyness of kerneli.org/cryptoapi:
> 
> 1)  You are trying to replace link/insmod time overhead with runtime
>     overhead + unnecessary bloat.
> 2)  No direct link access to low level cipher functions or higher level
>     functions.
> 3)  No clean way to replace cipher code with processor type optimized
>     assembler implementations.

Jari has a few points here.  But the "killer" functionalities are all there
IMHO.  Low-level assembler implementations are over-rated, again IMHO.  The
performance difference between C and ASM is at most 50%.  1ms vs 1.5 ms.
Even if you've got a large payload on the rare occation (>5MB) block ciphers
are quite fast for 95% of applications

JLC

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6
C: 613.263.2983

Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec

[JuanJo Ciarlante]

On Thu, Oct 24, 2002 at 10:50:26AM -0400, Jean-Luc Cooke wrote:
> On Tue, Oct 22, 2002 at 08:02:00AM +0300, Jari Ruusu wrote:
> > kerneli.org/cryptoapi _is_ useless joke for many needs. Fortunately other
> > people are able to see the limitations/sillyness of kerneli.org/cryptoapi:
> > 
> > 1)  You are trying to replace link/insmod time overhead with runtime
> >     overhead + unnecessary bloat.
> > 2)  No direct link access to low level cipher functions or higher level
> >     functions.
> > 3)  No clean way to replace cipher code with processor type optimized
> >     assembler implementations.
> 
> Jari has a few points here.  But the "killer" functionalities are all there
> IMHO.  Low-level assembler implementations are over-rated, again IMHO.  The
> performance difference between C and ASM is at most 50%.  1ms vs 1.5 ms.
> Even if you've got a large payload on the rare occation (>5MB) block ciphers
> are quite fast for 95% of applications

According to my tests, AES ASM has given me _2x_ speed boost over C; this
fact has re-written freeswan CPU/bandwidth empirical formula to peak at
       CPU [MHz] ~= BW [Mbit/s] * 10      (instead of 25)

This boost has allowed my old Cyrix-6x86 120MHz to be my 802.11b gateway  =)


--Juanjo       freeswan algo: AES (+others), SHA2, MODP2048-4096 
               selectable algorithms support for Phase1 and 2.
	       http://www.irrigacion.gov.ar/juanjo/ipsec/

#  Juan Jose Ciarlante (JuanJo PGP) jjo ;at; mendoza.gov.ar              #
#  Key fingerprint = 76 60 A5 76 FD D2 53 E3  50 C7 90 20 22 8C F1 2D    #