\documentclass{article}
\usepackage{hyperref}

\author{Brad Marshall {\tt <brad.marshall@member.sage-au.org.au>}}
\title{Introduction to IPSec}

\begin{document}

\maketitle

\tableofcontents

\section{Introduction to IPSec}

Many of you would have heard of IPSec, but may know nothing about it.
It was first proposed in RFC1825 way back in August of 1995 (later
updated in RFC2401 in November of 1998) as a means of embedding
security into both IPv4 and IPv6. There were several properties to
consider for data - authentication, integrity, confidentiality and
non-repudiation. There are occasions when sometimes only one of these
are important, and times when you require all.

The IPSec architecuture doesn't force any particular encryption or
authentication algorithms on the user - it is all completely
replaceable with whatever algorithm you want. However, the RFCs
specify certain algorithms that should be implemented for
compatibility reasons.

IPsec can be deployed to protect data going between two hosts, between
a host and a router / firewall, or between two routers / firewalls. It
also gives fine grained control as to how the security is implemented
- what services to use where, what combination, and what algorithms to
use.

However, IPSec is not an end to end solution - it can only
encrypt traffic as it travels over the network.  You will
still need to protect the data on the destination machines,
if required.  IPSec can also only authenticate machines, not
users - you will still need to have user based authenticaton
on your applications etc.

\subsection{IPSec Protocols}

There are several protocols used in IPSec that are important to
understand. The Authentication Header, or AH, is used as the name
suggests to authenticate the packets, and optionally anti-replay
protection. This is used soley to ensure knowledge of who the sender
is, and by itself gives no confidentiality of data. However, due to
various crypto laws around the world it is perhaps easier to implement
politically due to the lack of encryption. 

IP Encapsulating Security Payload header, or ESP, is used
to ensure that the data transmitted between the two hosts
securely, optionally with authentication and integrity
checking. Regardless, using either (or both) of these protocols
gives you access control over the data.

The Internet Key Exchange, or IKE, negotiates the connection
parameters, which includes what type of connection, what
encryption algorithms to use, and what keys are used.

\section{FreeS/WAN}

The Linux implementation of IPSec is FreeS/WAN.  It 
is available from http://www.freeswan.org/.

FreeS/WAN consists of 3 main parts:

\begin{description}
\item KLIPS - Kernel IPSec, implements AH and ESP
\item Pluto - IKE daemon
\end{description}

\subsection{Installing FreeS/WAN}

Installing FreeS/WAN consists of two main parts - patches to
the kernel, and some userspace tools and daemons.  The example
that follows assumes you are using a recent version of Debian
GNU/Linux.

\subsubsection{Kernel Patches}

The following is a brief description of how to install, patch
and compile a Debian kernel package with support for FreeS/WAN.
It assumes you have a recent 2.4 kernel (2.4.18 as of time of
writing) untarred in /usr/src/linux.

\begin{verbatim}
  $ sudo apt-get install kernel-package kernel-patch-freeswan
  $ cd /usr/src/linux
  $ export PATCH_THE_KERNEL=YES
  $ make-kpkg --config=menuconfig --revision=host1.0 configure
\end{verbatim}

At a minimum, you need the following kernel config options selected:

\begin{verbatim}
  CONFIG_IPSEC
  CONFIG_IPSEC_IPIP
  CONFIG_IPSEC_AH
  CONFIG_IPSEC_ESP
\end{verbatim}

Once you've configured the kernel appropriately, and optionally
saved your kernel configuration somewhere, run the following:

\begin{verbatim}
  $ fakeroot make-kpkg binary-arch
\end{verbatim}

Now, install the kernel package (it will
be in /usr/src, and named something like
kernel-image-2.4.18\verb+_+host1.0\verb+_+i386.deb) and reboot.

\subsubsection{Userspace daemons and tools}

Under Debian installing the userspace daemons and tools is
fairly simple - you do something like:

\begin{verbatim}
  $ sudo apt-get install freeswan
\end{verbatim}

This will install all the necessary init scripts, and optionally
create an x509 or RSA key for you.

\subsection{Configuration}

FreeS/WAN configuration is done by \verb+/etc/ipsec.conf+,
and RSA keys and preshared secrets are kept in
\verb+/etc/ipsec.secrets+.

There are 3 main types of networks that IPSec can provide a
solution for - road warriors, subnet to subnet, and client
behind NAT.

\subsubsection{Road Warrior}

A road warrior is simply a machine that's out on the internet
somewhere, which may or may not have a static ip address, and
wishes to communicate back to the office.  The most common
example of this situation is that of a laptop dialed up to
some ISP.  This is perhaps the simplest case, and is not very
hard to setup.

For the road warrior, \verb+/etc/ipsec.conf+ looks like:

\begin{verbatim}
conn road-warrior
    left=%defaultroute
    leftid=@hostname.identifier
    leftrsasigkey=0s ... rsa sig ...
    right=ip.add.ress
    rightid=@gw.hostname.identifier
    rightrsasigkey=0s ... rsa sig ...
    rightsubnet=local.ip.range.0/24
    rightnexthop=gw.default.route
    authby=rsasig
    auto=add
\end{verbatim}

On the server, \verb+/etc/ipsec.conf+ looks like:

\begin{verbatim}
conn vpn
    left=%any
    leftid=@hostname.identifier
    leftrsasigkey=0s ... rsa sig ...
    right=ip.address
    rightid=@stallman.pisoftware.com
    rightrsasigkey=0s ... rsa sig ...
    rightsubnet=local.ip.range.0/24
    rightnexthop=gw.default.route
    authby=rsasig
    auto=add
\end{verbatim}

\subsubsection{Subnet to Subnet}

This is the situation where you wish to have a subnet behind
a router of some kind talk to the office subnet.  This is
most common in the situation where you have a machine at home
providing network access for the rest of the house, and you
wish the entire network to see the ``office''.

The ``client'' \verb+/etc/ipsec.conf+ extract looks like:

\begin{verbatim}
conn client-subnet-vpn
    left=%defaultroute
    leftid=@host.identifier
    leftrsasigkey=0s...rsa sig...
    leftsubnet=local.ip.range.0/24
    right=server.ip.addr
    rightid=@gw.host.identifier
    rightrsasigkey=0s...rsa sig...
    rightsubnet=local.ip.range.0/24
    rightnexthop=gw.default.route
    authby=rsasig
    auto=start
\end{verbatim}

The ``server'' \verb+/etc/ipsec.conf+ extract looks like:

\begin{verbatim}
conn server-subnet-vpn
    left=%any
    leftid=@host.identifier
    leftrsasigkey=0s...rsa sig...
    leftsubnet=local.ip.range.0/24
    right=server.ip.addr
    rightid=@gw.host.identifier
    rightrsasigkey=0s...rsa sig...
    rightsubnet=local.ip.range.0/24
    rightnexthop=gw.default.route
    authby=rsasig
    auto=add
    # we don't want to retry if IP connectivity is gone
    keyingtries=1
    keylife=30m
    ikelifetime=30m
\end{verbatim}

\subsubsection{Client behind NAT}

In some cases it may be necessary for the client that initiates
the ipsec connection to be behind NAT.  In certain situations,
this is indeed possible, regardless of what you may have
read elsewhere.

In this network setup, the machine doing the NAT was running
a 2.4 linux kernel, with ip masquerading for the entire subnet
behind it.  The client that is initiating the connection needs
to have a static private IP address.

\begin{verbatim}
conn nat-vpn
    authby=rsasig
    left=%defaultroute
    leftsubnet=client.ip.add.ress/32
    leftnexthop=
    leftid=@client.identifier
    leftrsasigkey=0s...rsa sig...
    right=server.ip.add.ress
    rightid=@gw.identifier
    rightrsasigkey=0s...rsa sig...
    rightsubnet=local.ip.range.0/24
    rightnexthop=gw.default.route
    auto=add
\end{verbatim}

\begin{verbatim}
conn nat-vpn
    authby=rsasig
    left=0.0.0.0
    leftsubnet=client.ip.add.ress/32
    leftnexthop=
    leftid=@client.identifier
    leftrsasigkey=0s...rsa sig...
    right=server.ip.add.ress
    rightid=@gw.identifier
    rightrsasigkey=0s...rsa sig...
    rightsubnet=local.ip.range.0/24
    rightnexthop=gw.default.route
    auto=add
\end{verbatim}

\subsubsection{Complex combinations}

There are many possible network topologies that can be used with
IPSec, and the few that are covered above will not necessarily
be suffient for all needs.  However, in the general case, it is
possible to build up the network configurations required with
``blocks'' of the previously described setups.

\section{Firewall Issues}

There are 3 protocols you have to allow though a firewall
for complete operation of IPSec.  These are AH, ESP and IKE.
These firewall rules are examples from the Linux kernel 2.4
firewalling tool, iptables.  Converting to your preferred
firewalling tool shouldn't be hard.

\begin{verbatim}
# Allow IKE
/sbin/iptables -A INPUT -p udp --sport 500  -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 500  -j ACCEPT
# Allow ESP
/sbin/iptables -A INPUT -p 50 -j ACCEPT
# Allow AH
/sbin/iptables -A INPUT -p 51 -j ACCEPT
\end{verbatim}

\section{Conclusion}
As you've seen, there are many useful things you can do with
IPSec, but it is not a silver bullet for security.  You need
to have proper management of setting up the VPNs, and to be
careful that you are not opening yourself up to problems.
By allowing another network access to yours over a VPN it is
important to recognize that the security policy of the remote
end will affect yours.


\end{document}
