From aaa0331ecf95ced1e913ac9be50168cf0e7cbb82 Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Tue, 30 Jan 2007 12:21:07 +0000 Subject: [svn-upgrade] Integrating new upstream version, strongswan (2.8.2) --- doc/src/background.html | 376 ------------------------------------------------ 1 file changed, 376 deletions(-) delete mode 100644 doc/src/background.html (limited to 'doc/src/background.html') diff --git a/doc/src/background.html b/doc/src/background.html deleted file mode 100644 index e25b9da03..000000000 --- a/doc/src/background.html +++ /dev/null @@ -1,376 +0,0 @@ - - - - FreeS/WAN background - - - - - -

Linux FreeS/WAN background

- -

This section discusses a number of issues which have three things in -common:

- - -

Grouping them here lets us provide the explanations some users will need -without unduly complicating the main text.

- -

The explanations here are intended to be adequate for FreeS/WAN purposes -(please comment to the users mailing list if you -don't find them so), but they are not trying to be complete or definitive. If -you need more information, see the references provided in each section.

- -

Some DNS background

- -

Opportunistic encryption requires -that the gateway systems be able to fetch public keys, and other -IPsec-related information, from each other's DNS (Domain Name Service) -records.

- -

DNS is a distributed database that maps -names to IP addresses and vice versa.

- -

Much good reference material is available for DNS, including:

- - -

We give only a brief overview here, intended to help you use DNS for -FreeS/WAN purposes.

- -

Forward and reverse maps

- -

Although the implementation is distributed, it is often useful to speak of -DNS as if it were just two enormous tables:

- - -

Both maps can optionally contain additional data. For opportunistic -encryption, we insert the data need for IPsec authentication.

- -

A system named gateway.example.com with IP address 10.20.30.40 should have -at least two DNS records, one in each map:

-
-
gateway.example.com. IN A 10.20.30.40
-
used to look up the name and get an IP address
-
40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.
-
used for reverse lookups, looking up an address to get the associated - name. Notice that the digits here are in reverse order; the actual - address is 10.20.30.40 but we use 40.30.20.10 here.
-
- -

Hierarchy and delegation

- -

For both maps there is a hierarchy of DNS servers and a system of -delegating authority so that, for example:

- - -

DNS zones are the units of delegation. There is a hierarchy of zones.

- -

Syntax of DNS records

- -

Returning to the example records:

-
        gateway.example.com. IN A 10.20.30.40
-        40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.
- -

some syntactic details are:

- - -

The capitalised strings after IN indicate the type of record. Possible -types include:

- - -

To set up for opportunistic encryption, you add some TXT records -to your DNS data. Details are in our quickstart -document.

- -

Cacheing, TTL and propagation delay

- -

DNS information is extensively cached. With no caching, a lookup by your -system of "www.freeswan.org" might involve:

- - -

However, this can be a bit inefficient. For example, if you are in the -Phillipines, the closest a root server is in Japan. That might send you to a -.org server in the US, and then to freeswan.org in Holland. If everyone did -all those lookups every time they clicked on a web link, the net would grind -to a halt.

- -

Nameservers therefore cache information they look up. When you click on -another link at www.freeswan.org, your local nameserver has the IP address -for that server in its cache, and no further lookups are required.

- -

Intermediate results are also cached. If you next go to -lists.freeswan.org, your nameserver can just ask the freeswan.org nameserver -for that address; it does not need to query the root or .org nameservers -because it has a cached address for the freeswan.org zone server.

- -

Of course, like any cacheing mechanism, this can create problems of -consistency. What if the administrator for freeswan.org changes the IP -address, or the authentication key, for www.freeswan.org? If you use old -information from the cache, you may get it wrong. On the other hand, you -cannot afford to look up fresh information every time. Nor can you expect the -freeswan.org server to notify you; that isn't in the protocols.

- -

The solution that is in the protocols is fairly simple. Cacheable records -are marked with Time To Live (TTL) information. When the time expires, the -caching server discards the record. The next time someone asks for it, the -server fetches a fresh copy. Of course, a server may also discard records -before their TTL expires if it is running out of cache space.

- -

This implies that there will be some delay before the new version of a -changed record propagates around the net. Until the TTLs on all copies of the -old record expire, some users will see it because that is what is in their -cache. Other users may see the new record immediately because they don't have -an old one cached.

- -

Problems with packet fragmentation

- -

It seems, from mailing list reports, to be moderately common for problems -to crop up in which small packets pass through the IPsec tunnels just fine -but larger packets fail.

- -

These problems are caused by various devices along the way mis-handling -either packet fragments or path MTU -discovery.

- -

IPsec makes packets larger by adding an ESP or AH header. This can tickle -assorted bugs in fragment handling in routers and firewalls, or in path MTU -discovery mechanisms, and cause a variety of symptoms which are both annoying -and, often, quite hard to diagnose.

- -

An explanation from project technical lead Henry Spencer:

-
The problem is IP fragmentation; more precisely, the problem is that the
-second, third, etc. fragments of an IP packet are often difficult for
-filtering mechanisms to classify.
-
-Routers cannot rely on reassembling the packet, or remembering what was in
-earlier fragments, because the fragments may be out of order or may even
-follow different routes.  So any general, worst-case filtering decision
-pretty much has to be made on each fragment independently.  (If the router
-knows that it is the only route to the destination, so all fragments
-*must* pass through it, reassembly would be possible... but most routers
-don't want to bother with the complications of that.)
-
-All fragments carry roughly the original IP header, but any higher-level
-header is (for IP purposes) just the first part of the packet data... so
-only the first fragment carries that.  So, for example, on examining the
-second fragment of a TCP packet, you could tell that it's TCP, but not
-what port number it is destined for -- that information is in the TCP
-header, which appears in the first fragment only. 
-
-The result of this classification difficulty is that stupid routers and
-over-paranoid firewalls may just throw fragments away.  To get through
-them, you must reduce your MTU enough that fragmentation will not occur.
-(In some cases, they might be willing to attempt reassembly, but have very
-limited resources to devote to it, meaning that packets must be small and
-fragments few in number, leading to the same conclusion:  smaller MTU.)
- -

In addition to the problem Henry describes, you may also have trouble with -path MTU discovery.

- -

By default, FreeS/WAN uses a large MTU for -the ipsec device. This avoids some problems, but may complicate others. -Here's an explanation from Claudia:

-
Here are a couple of pieces of background information. Apologies if you
-have seen these already. An excerpt from one of my old posts:
-
-    An MTU of 16260 on ipsec0 is usual. The IPSec device defaults to this 
-    high MTU so that it does not fragment incoming packets before encryption 
-    and encapsulation. If after IPSec processing packets are larger than 1500,
-    [ie. the mtu of eth0] then eth0 will fragment them. 
-
-    Adding IPSec headers adds a certain number of bytes to each packet. 
-    The MTU of the IPSec interface refers to the maximum size of the packet
-    before the IPSec headers are added. In some cases, people find it helpful 
-    to set ipsec0's MTU to 1500-(IPSec header size), which IIRC is about 1430.
-
-    That way, the resulting encapsulated packets don't exceed 1500. On most 
-    networks, packets less than 1500 will not need to be fragmented.
-
-and... (from Henry Spencer)
-
-    The way it *ought* to work is that the MTU advertised by the ipsecN
-    interface should be that of the underlying hardware interface, less a
-    pinch for the extra headers needed. 
-
-    Unfortunately, in certain situations this breaks many applications.
-    There is a widespread implicit assumption that the smallest MTUs are 
-    at the ends of paths, not in the middle, and another that MTUs are 
-    never less than 1500.  A lot of code is unprepared to handle paths 
-    where there is an "interior minimum" in the MTU, especially when it's 
-    less than 1500. So we advertise a big MTU and just let the resulting 
-    big packets fragment.
-
-This usually works, but we do get bitten in cases where some intermediate
-point can't handle all that fragmentation.  We can't win on this one.
- -

The MTU can be changed with an overridemtu= statement in the -config setup section of ipsec.conf.5.

- -

For a discussion of MTU issues and some possible solutions using Linux -advanced routing facilities, see the Linux -2.4 Advanced Routing HOWTO. - -For a discussion of MTU and NAT (Network Address Translation), see -James Carter's MTU -notes.

- -

Network address translation (NAT)

- -

Network Address -Translation is a service provided by some gateway machines. -Calling it NAPT (adding the word Port) would be more -precise, but we will follow the widespread usage.

- -

A gateway doing NAT rewrites the headers of packets it is forwarding, -changing one or more of:

- - -

On Linux 2.4, NAT services are provided by the netfilter(8) firewall code. There are -several Netfilter -HowTos including one on NAT.

- -

For older versions of Linux, this was referred to as "IP masquerade" and -different tools were used. See this resource page.

- -

Putting an IPsec gateway behind a NAT gateway is not recommended. See our -firewalls document.

- -

NAT to non-routable addresses

- -

The most common application of NAT uses private non-routable addresses.

- -

Often a home or small office network will have:

- - -

Of course this poses a problem since several machines cannot use one -address. The best solution might be to obtain more addresses, but often this -is impractical or uneconomical.

- -

A common solution is to have:

- - -

The client machines are set up with reserved non-routable IP addresses defined in RFC 1918. The -masquerading gateway, the machine with the actual link to the Internet, -rewrites packet headers so that all packets going onto the Internet appear to -come from one IP address, that of its Internet interface. It then gets all -the replies, does some table lookups and more header rewriting, and delivers -the replies to the appropriate client machines.

- -

As far as anyone else on the Internet is concerned, the systems behind the -gateway are completely hidden. Only one machine with one IP address is -visible.

- -

For IPsec on such a gateway, you can entirely ignore the NAT in:

- - -

Those can be set up exactly as they would be if your gateway had no other -systems behind it.

- -

You do, however, have to take account of the NAT in firewall rules which -affect packet forwarding.

- -

NAT to routable addresses

- -

NAT to routable addresses is also possible, but is less common and may -make for rather tricky routing problems. We will not discuss it here. See the -Netfilter -HowTos.

- - -- cgit v1.2.3