\section{What do we really need}

\subsection{A brief primer on IPsec}

IPsec\cite{RFC2411},\cite{RFC2401} consists of three transport layer protocols:
AH\cite{RFC2402}, ESP\cite{RFC2406} and IPcomp\cite{RFC2507}. There is one
management protocol in existence at this time,
ISAKMP\cite{RFC2408}/IKE\cite{RFC2407},\cite{RFC2409}. 

These transport protocols can be applied to upper layers of TCP, UDP, or any
other transport protocol. When the upper layer is the ``IPIP''\cite{RFC2003},
then the protocol is said to be in ``tunnel'' mode. For most Virtual Private
Network (VPN) usages, tunnel mode is the preferred method since it hides the
origina source/destination address. VPNs are often treated as being virtual
leased lines.

Each of the transport protocols provide session layer encryption. They are
referred to as ``security associations''. These are unidirectional concepts - 
a pair is usually needed for bidirectional communications.

\subsubsection{Authentication Header (AH)}

The Authentication Header provides origin authentication and integrity of the 
headers and of the data portion. No privacy is provided.

\subsubsection{Encapsulating Security Payload (ESP)}

The ESP header provides origin authentication, integrity and optional privacy 
of the data portion only. Normally, this privacy option is provided by
encryption, but the specification permits a ``null'' encryption to be used in 
some circumstances.

\subsubsection{IP compression header (IPcomp)}

A good encryption algorithm produces cyphertext that is evenly
distributed. This makes it difficult to compress. If one wishes to compress
the data it must be done prior to encrypting. The IPcomp header provides for this.

One of the problems of tunnel mode is that it adds 20 bytes of IP header,
plus 28 bytes of ESP overhead to each packet. This can cause large packets to
be fragmented. Compressing the packet first may make it small enough to avoid 
this fragmentation.

\subsubsection{Internet Security Association Key Management Protocol (ISAKMP)}

ISAKMP is a framework for doing Security Association Key Management. It can,
in theory, be used to produce session keys for many different systems, not
just IPsec.

\subsubsection{Internet Key Daemon (IKE)}

IKE is a profile of ISAKMP that is for use by IPsec. It is often called simply
``IKE''. IKE creates a private, authenticated key management channel. Using
that channel, two peers can communicate, arranging for sessions keys to be
generated for AH, ESP or IPcomp. The channel is used for the peers to agree
on the encryption, authentication and compression algorithms that will be
used. The traffic to which the policies will applied is also agreed upon.

\subsection{Testing KLIPS}

In FreeSWAN, the session layer encryption, security association management
and traffic selection is done by a kernel component called KLIPS (Kernel Level
IP Security). This component can be built as a loadable kernel module or
statically built in. 

As the security associations are unidirectional one can effectively seperate
the encrypt/encapsulate and decrypt/decapsulate operations for testing
purposes.

For ease of thinking, the encryption operations are always done on {\scshape
EAST} and the decryption operations are always done on {\scshape WEST}.

\begin{figure}
\includegraphics[height=3in,width=5in]{klipstest.eps} 
\caption{How to test KLIPS}
\label{klipstest}
\end{figure}

As indicated in figure \ref{klipstest}, a source of plaintext packets is
needed, a way to examine the ciphertext packets is needed, and a way to
configure the system is needed. In the physical setup of the previous
section, the source of plaintext packets is provided by the machine {\scshape
SUNRISE}, and the examination of the packets is provided by {\scshape SKY}.  

A typical initialization script for KLIPS is shown below:

\begin{verbatim}
#!/bin/sh
TZ=GMT export TZ

ipsec spi --clear
ipsec eroute --clear

enckey=0x4043434545464649494a4a4c4c4f4f515152525454575758
authkey=0x87658765876587658765876587658765

ipsec klipsdebug --set pfkey
ipsec klipsdebug --set verbose

ipsec spi --af inet --edst 192.1.2.45 --spi 0x12345678 --proto esp --src 192.1.2.23 --esp 3des-md5-96 --enckey $enckey --authkey $authkey

ipsec spi --af inet --edst 192.1.2.45 --spi 0x12345678 --proto tun --src 192.1.2.23 --dst 192.1.2.45 --ip4

ipsec spigrp inet 192.1.2.45 0x12345678 tun inet 192.1.2.45 0x12345678 esp 

ipsec eroute --add --eraf inet --src 192.0.2.0/24 --dst 192.0.1.0/24 --said tun0x12345678@192.1.2.45

ipsec tncfg --attach --virtual ipsec0 --physical eth1
ifconfig ipsec0 inet 192.1.2.23 netmask 0xffffff00 broadcast 192.1.2.255 up

# magic route command
route add -host 192.0.1.1 gw 192.1.2.45 dev ipsec0

ipsec look
\end{verbatim}

The term SPI means ``Security Parameters Index''. Each security association
is indexed by a SPI. Note that a seperate SPI is setup for the ESP operation
and for the tunnel operation. The two are then grouped together. 

The {\tt eroute} (Extended Route) command then selects traffic by source and
destination address for processing by the afore mentioned
group. \cite{RFC2401} defines other selectors, including TCP and UDP port
numbers, but those selectors are not implemented in KLIPS at this time.

The {\tt tncfg} command attaches the IPsec pseudo to a physical device. This
is necessary in 2.0 and prior kernels to provide a path for the resulting
packets to actually leave the system. Otherwise, the {\tt route} command at
the end can cause packets to loop internally. Eliminating this problem -- 
we refer to it as ``stoopid routing tricks''<tm> -- is the major goal of
revisions to KLIPS.

The {\tt ipsec klipsdebug} commands turn on various debugging output. This
debugging output is important for diagnosing what has really happened when
the system fails.

Finally, the {\tt ipsec look} command produces a short summary of resulting
system setup. The output of this looks like:

\begin{verbatim}
east Tue Apr  2 04:32:28 GMT 2002
192.0.2.0/24       -> 192.0.1.0/24       => tun0x12345678@192.1.2.45 esp0x12345678@192.1.2.45  (0)
ipsec0->eth1 mtu=16260(1500)->1500
esp0x12345678@192.1.2.45 ESP_3DES_HMAC_MD5: dir=out src=192.1.2.23 iv_bits=64bits iv=0x24a4a14e81ee960e alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(9,0,0)
tun0x12345678@192.1.2.45 IPIP: dir=out src=192.1.2.23 life(c,s,h)=addtime(9,0,0)
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.0.1.1       192.1.2.45      255.255.255.255 UGH      40 0          0 ipsec0
192.1.2.0       0.0.0.0         255.255.255.0   U        40 0          0 eth1
192.1.2.0       0.0.0.0         255.255.255.0   U        40 0          0 ipsec0
192.0.1.0       192.1.2.45      255.255.255.0   UG       40 0          0 eth1
192.0.2.0       0.0.0.0         255.255.255.0   U        40 0          0 eth0
0.0.0.0         192.1.2.254     0.0.0.0         UG       40 0          0 eth1
\end{verbatim} 

At this point, the system is ready to have packets sent through it. If the
packets match the criteria for the SA, then they will be encrypted with the
provided key.

\subsubsection{KLIPS hassles}

The observant will notice a number of numbers in the above output which were
not in the script: the IV field ({\tt 0x24a4a14e81ee960e}), the lifetime
values (it has been 9 seconds between the SA was created and the look
command occured), and the date.

These variances cause two problems: the console output is not consistent on
every run, and the resulting encrypted packets will have different ciphertext 
on each run. 

%The console output problem can be handled by removing pieces which are not
%relevant in a post processing way. 
% (Note the forcing of the time zone at the beginning of the
% script. This was done so that all dates would have the string ``GMT'' in them)
% The difference in the ciphertext can be
%handled by not comparing the ciphertext directly - rather an independant
%program can be used to decre

\subsection{Testing Pluto}

Pluto requires two machines to do any testing. Pluto has to talk to
a peer that understand the ISAKMP/IKE protocol. 

Where IPsec can be configured easily to be in a static, or at least,
predictable state, ISAKMP/IKE can not. The protocol has extensive facilities
to prevent replay attacks, does all of its operations in private and
generates random keys for use by the KLIPS system.

\begin{figure}
\includegraphics[height=2in,width=3in]{plutotest.eps} 
\caption{How to test Pluto}
\label{plutotest}
\end{figure}

Most actions that Pluto performs are done in response to
network traffic. There are three kinds of traffic that causes pluto to
change states:
\begin{itemize}
\item IP traffic caught by KLIPS, that causes PF\_KEY traffic to pluto.
\item another host that wants to initiate keying with this host.
\item replies to DNS queries that pluto sends.
\end{itemize}

In addition, timeouts are important. To test pluto you either have to
configure rather small timeouts - which can cause race conditions, or
one has to be very patient. A way to artificially advance the clock
would help.


