USAGI IPsec

USAGI IPsec

Post by Mitsuru KAND » Sun, 13 Oct 2002 04:00:08



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...
    (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 <lat...@austin.ibm.com>
        and IBM IPv6 team

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

USAGI IPsec

Post by David S. Mille » Sun, 13 Oct 2002 04:10:04


Hello.

We will be using your ipv6 ipsec work as a model for how
IPSEC will look in Linux.

We liked your implementation for it's simplicity.  But Alexey and
myself believe several details should be handled very much
differently.

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

USAGI IPsec

Post by Arnaldo Carvalho de Mel » Sun, 13 Oct 2002 04:30:04


Em Fri, Oct 11, 2002 at 06:53:32PM -0700, David S. Miller escreveu:

Quote:> We will be using your ipv6 ipsec work as a model for how
> IPSEC will look in Linux.

Wohoo, and there are still people thinking that 2.5 has not exciting things,
bah, I found it great to have so much work finally merged.

Quote:> We liked your implementation for it's simplicity.  But Alexey and myself
> believe several details should be handled very much differently.

It will make it better, I'm sure.

Congratulations to the USAGI people!

- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

USAGI IPsec

Post by YOSHIFUJI Hideaki / 吉藤英 » Sun, 13 Oct 2002 04:50:03



Quote:> We liked your implementation for it's simplicity.  But Alexey and
> myself believe several details should be handled very much
> differently.

Would you tell us the points of the "several details," please?

--

GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

USAGI IPsec

Post by David S. Mille » Sun, 13 Oct 2002 04:50:04



   Date: Sat, 12 Oct 2002 11:43:30 +0900 (JST)

   Would you tell us the points of the "several details," please?

We believe that the whole SPD/SAD mechanism should move
eventually to a top-level flow cache shared by ipv4 and
ipv6.

Therefore all the interfaces will be architected such that
a move to a flow cache based lookup system will be a very
simple change.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

USAGI IPsec

Post by bert huber » Sun, 13 Oct 2002 13:20:07




>    Date: Sat, 12 Oct 2002 11:43:30 +0900 (JST)

>    Would you tell us the points of the "several details," please?

> We believe that the whole SPD/SAD mechanism should move
> eventually to a top-level flow cache shared by ipv4 and
> ipv6.

Is this the proposed stacked route system?

Regards,

bert hubert

--
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

USAGI IPsec

Post by David S. Mille » Sun, 13 Oct 2002 13:50:07



   Date: Sat, 12 Oct 2002 13:17:59 +0200


   > We believe that the whole SPD/SAD mechanism should move
   > eventually to a top-level flow cache shared by ipv4 and
   > ipv6.

   Is this the proposed stacked route system?

Yes, for output mostly.

Also the idea Alexey and I have to move towards a small
efficient flow cache shared by IPv4/IPv6 plays into this
as well.  There are changesets on their way to Linus tonight
which moves ipv4 over to using ipv6's "struct flowi" from
include/net/flow.h as the routing lookup key.

The initial ipsec is intended to be simple, singly linked
lists for the spd/sad databases etc.  Making the feature
freeze is pretty important right now, full blown flow cache
is just performance improvement :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

USAGI IPsec

Post by Stephan von Krawczynsk » Sun, 13 Oct 2002 14:10:07


On Sat, 12 Oct 2002 04:41:37 -0700 (PDT)


>    Date: Sat, 12 Oct 2002 13:17:59 +0200


>    > We believe that the whole SPD/SAD mechanism should move
>    > eventually to a top-level flow cache shared by ipv4 and
>    > ipv6.

>    Is this the proposed stacked route system?

> Yes, for output mostly.

> Also the idea Alexey and I have to move towards a small
> efficient flow cache shared by IPv4/IPv6 plays into this
> as well.  There are changesets on their way to Linus tonight
> which moves ipv4 over to using ipv6's "struct flowi" from
> include/net/flow.h as the routing lookup key.

> The initial ipsec is intended to be simple, singly linked
> lists for the spd/sad databases etc.  Making the feature
> freeze is pretty important right now, full blown flow cache
> is just performance improvement :)

Huhu!
Just a word on this one: I recently came across some heavy performance problem
regarding a setup with about 225 000 routes. It looked as if TCP experienced a
tremendous slowdown to about 50 KBytes/sec throughput, whereas UDP worked
pretty much normal. This was a 2.2.19 kernel with equal-cost-multipath enabled
and large routing-tables enabled.
The reason I am writing this is: please keep in mind situations like this with
several hundred thousands of routes in one box. This is a familiar setup for
the routing guys - and not a "just" case ;-)
Thanks for lending an ear.
--
Regards,
Stephan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

USAGI IPsec

Post by bert huber » Sun, 13 Oct 2002 14:20:09



> Also the idea Alexey and I have to move towards a small
> efficient flow cache shared by IPv4/IPv6 plays into this
> as well.  There are changesets on their way to Linus tonight

Some people on #lartc were wondering about the use of a route cache if there
is only one route. It was reported that a single default route on a system
that talks to many destinations would lead to a huge route cache, which is
probably not more efficient than looking up the simple route.

Would this 'small efficient flow cache' also solve this problem?

Or is this problem a figment of people's imaginations?

Quote:> The initial ipsec is intended to be simple, singly linked
> lists for the spd/sad databases etc.  Making the feature
> freeze is pretty important right now, full blown flow cache
> is just performance improvement :)

I know a lot of people are hoping that you make the feature freeze. As said
before, if there is any help you need, just yell.

Regards,

bert

--
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

USAGI IPsec

Post by David S. Mille » Mon, 14 Oct 2002 08:00:04



   Date: Sat, 12 Oct 2002 14:06:44 +0200

   This was a 2.2.19 kernel with equal-cost-multipath enabled
   and large routing-tables enabled.

It doesn't surprise me that 2.2.x performs like *under
any real load btw :-)  It has none of the 2.3.x scalability
and threading work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

USAGI IPsec

Post by David S. Mille » Mon, 14 Oct 2002 08:00:06



   Date: Sat, 12 Oct 2002 14:16:50 +0200

   Some people on #lartc were wondering about the use of a route cache if there
   is only one route. It was reported that a single default route on a system
   that talks to many destinations would lead to a huge route cache, which is
   probably not more efficient than looking up the simple route.

   Would this 'small efficient flow cache' also solve this problem?

I contend there is no "problem".  Routing cache entries are
garbage collected, and even this can be tuned via sysctl.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. [PATCH] USAGI IPsec

   [snip]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Networking SUN And DEC

3. (usagi-core 12294) Re: [PATCH] IPv6 IPsec support

4. why spaces stripped off ??

5. ipsec masq--ipsec ports?

6. How to login without entering passwd

7. Multiple Outgoing IPSEC SAs ( Sun Solaris 9, IKE/IPSEC)

8. DX4/100 System for Linux?

9. IPSec/VPN to Cisco router with IPSec IOS ?

10. Solaris and IPsec, non IPsec aware boxes on network.

11. To IPsec or not to IPsec

12. IPSEC Howto i can buil IPSec tunnel...

13. FreeSWAN IPsec and SSH Sentinel IPSec client