[ale] IPSEC Operations Issues

[Chris Ricker]

<Ryan, I'm CC'ing this through ALE as well -- hope you don't mind.  Below is
my understanding of why ESP / AH differ in terms of compatibility w/ NAT,
but someone else may have a more coherent take on it>

On 27 Sep 2002, Ryan Matteson wrote:

> On Fri, 2002-09-27 at 13:14, Chris Ricker wrote:
> >
> > Mostly.  The SPI is just a 32-bit number though.  The SA is stored elsewhere
> > (usually in some sort of config file / database), and identified by that
> > number.
> >
> 
> So the SPI is just an index into the Security Policy Database? And
> the SPI value in the database references the keys and cryptographic
> algorithms?

Yep!

> > Also, keep in mind that you're diagramming a connection which would
> > absolutely require NAT, and AH is incompatible with NAT (ESP is not,
> > though)
> 
> Thanks for the note. Does the ESP Mac Authentication field cover
> the SRC IP or DEST IP? I would think if the MAC was applied to the IP
> addresses, ESP would also break when NATs were used?

That depends.  (as you're quickly discovering, IPSec is in many ways 
horrendously over-engineered ;-)

ESP and AH can both be done in two different modes, transport or tunnel.  
Transport modifies (adds encryption / authentication info to) the existing
IP packet, while tunnel encapsulates it within a new IP packet.

AH transport looks something like:

 ______________________________________________________
| original IP header | AH | TCP / UDP header | payload |
 ------------------------------------------------------
< ---------------- Authenticated --------------------->

AH tunnel looks something like:

 __________________________________________________________________
| new IP header | AH | orig IP header | TCP / UDP header | payload |
 ------------------------------------------------------------------
<-------------------------- Authenticated ------------------------->


AH authenticates almost everything in either mode, though it does always
exclude a few fields in the IP header which have to be dynamic as the packet
is routed; specifically, I think ToS, Flags, Fragment, TTL, and the chksum
aren't included in the AH chksum.  As a result, neither NAT nor PAT are
compatible with AH.

ESP's a little different.  It can't encrypt the IP header, since the header
must be accessible for routing decisions as the packet traverses the
network.  This is going to mean that NAT (usually) works, but PAT still 
doesn't.

ESP transport looks something like:
 _____________________________________________________________
| original IP header | ESP | TCP / UDP header | payload | ESP |
 -------------------------------------------------------------
                           <--------- Authenticated ---->
                     <-------------- Encrypted --------->

ESP tunnel looks something like:

 _________________________________________________________________________
| new IP header | ESP | orig IP header | TCP / UDP header | payload | ESP |
 -------------------------------------------------------------------------
                      <--------------- Authenticated --------------->
                <---------------- Encrypted ------------------------>

So, in ESP transport mode the IP header isn't secured; NAT works fine.  In
ESP tunnel mode the original IP header is secured, but the encapsulating IP
header isn't.  Whether NAT will be problematic or not will depend on both
where the NAT is occurring, and where the IPSec encapsulation /
decapsulation is occurring.  In either transport or tunnel mode, the TCP /
UDP segment header is encrypted, so PAT is not possible....

> Do you use SKIP or ISAKMP for key exchanges? Or do you use pre-shared
> secrets on both ends? I am also trying to find out What the difference
> phases are used for.

I mostly use ISAKMP, except when dealing with implementations which don't
support it, in which case, I use pre-shared (eg, I use in.iked on Solaris 9,
and can't on Solaris 8).  I sometimes use Opportunistic Encryption (OE) as
well.

AFAIK, OE is only implemented by FreeS/WAN (the most commonly used Linux
IPSec implementation).  The idea behind it is that it's completely
configuration-free key exchange.  Keys are stored as TXT records in the DNS,
and when you connect to a remote system, the necessary keys are retrieved
from DNS by a reverse lookup and then automatically used for the connection.  
Of course, it has some drawbacks (no one's reverse DNS records are correct,
relatively speaking, and many people don't have the power to change that;
also, relying on anything obtained from DNS is more than a little iffy w/o
DNSSEC, and DNSSEC is even *more* over-engineered and less implemented than
IPSec), but it's a nice goal.  You can find the IETF draft about it at
<http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/draft-richardson-ipsec-opportunistic.html>

I've been playing with OE a bit on my home network, but am currently stymied
there by my ISP, which refuses to add my keys to my reverse DNS records.  
It's set up at work as well, but last time I looked through the logs it
looked like only two sites we connect to / that connect to us had ever used
it (and we had ~65,000 web connections yesterday, to give you an idea of the
total connecting volume), which should give you an idea of just how rarely
it's currently deployed, and why it's so rarely deployed right now....

later,
chris


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.