freeswan/doc/src/background.html

   1 <html>
   2 <head>
   3   <meta http-equiv="Content-Type" content="text/html">
   4   <title>FreeS/WAN background</title>
   5   <meta name="keywords" content="Linux, IPSEC, VPN, security, FreeSWAN">
   6   <!--
   7
   8   Written by Sandy Harris for the Linux FreeS/WAN project
   9   Freely distributable under the GNU General Public License
  10
  11   More information at www.freeswan.org
  12   Feedback to users@lists.freeswan.org
  13
  14   CVS information:
  15   RCS ID:          $Id: background.html,v 1.13 2002/03/26 16:44:08 sandy Exp $
  16   Last changed:    $Date: 2002/03/26 16:44:08 $
  17   Revision number: $Revision: 1.13 $
  18
  19   CVS revision numbers do not correspond to FreeS/WAN release numbers.
  20   -->
  21 </head>
  22
  23 <body>
  24 <h1><a name="background">Linux FreeS/WAN background</a></h1>
  25
  26 <p>This section discusses a number of issues which have three things in
  27 common:</p>
  28 <ul>
  29   <li>They are not specifically FreeS/WAN problems</li>
  30   <li>You may have to understand them to get FreeS/WAN working right</li>
  31   <li>They are not simple questions</li>
  32 </ul>
  33
  34 <p>Grouping them here lets us provide the explanations some users will need
  35 without unduly complicating the main text.</p>
  36
  37 <p>The explanations here are intended to be adequate for FreeS/WAN purposes
  38 (please comment to the <a href="mail.html">users mailing list</a> if you
  39 don't find them so), but they are not trying to be complete or definitive. If
  40 you need more information, see the references provided in each section.</p>
  41
  42 <h2><a name="dns.background">Some DNS background</a></h2>
  43
  44 <p><a href="glossary.html#carpediem">Opportunistic encryption</a> requires
  45 that the gateway systems be able to fetch public keys, and other
  46 IPsec-related information, from each other's DNS (Domain Name Service)
  47 records.</p>
  48
  49 <p><a href="glossary.html#DNS">DNS</a> is a distributed database that maps
  50 names to IP addresses and vice versa.</p>
  51
  52 <p>Much good reference material is available for DNS, including:</p>
  53 <ul>
  54   <li>the <a href="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html">DNS
  55   HowTo</a></li>
  56   <li>the standard <a href="biblio.html#DNS.book">DNS reference</a> book</li>
  57   <li><a href="http://www.linuxdoc.org/LDP/nag2/index.html">Linux Network
  58     Administrator's Guide</a></li>
  59   <li><a
  60     href="http://www.nominum.com/resources/whitepapers/bind-white-paper.html">BIND
  61     overview</a></li>
  62   <li><a
  63     href="http://www.nominum.com/resources/documentation/Bv9ARM.pdf">BIND 9
  64     Administrator's Reference</a></li>
  65 </ul>
  66
  67 <p>We give only a brief overview here, intended to help you use DNS for
  68 FreeS/WAN purposes.</p>
  69
  70 <h3><a name="forward.reverse">Forward and reverse maps</a></h3>
  71
  72 <p>Although the implementation is distributed, it is often useful to speak of
  73 DNS as if it were just two enormous tables:</p>
  74 <ul>
  75   <li>the forward map: look up a name, get an IP address</li>
  76   <li>the reverse map: look up an IP address, get a name</li>
  77 </ul>
  78
  79 <p>Both maps can optionally contain additional data. For opportunistic
  80 encryption, we insert the data need for IPsec authentication.</p>
  81
  82 <p>A system named gateway.example.com with IP address 10.20.30.40 should have
  83 at least two DNS records, one in each map:</p>
  84 <dl>
  85   <dt>gateway.example.com. IN A 10.20.30.40</dt>
  86     <dd>used to look up the name and get an IP address</dd>
  87   <dt>40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.</dt>
  88     <dd>used for reverse lookups, looking up an address to get the associated
  89       name. Notice that the digits here are in reverse order; the actual
  90       address is 10.20.30.40 but we use 40.30.20.10 here.</dd>
  91 </dl>
  92
  93 <h3>Hierarchy and delegation</h3>
  94
  95 <p>For both maps there is a hierarchy of DNS servers and a system of
  96 delegating authority so that, for example:</p>
  97 <ul>
  98   <li>the DNS administrator for example.com can create entries of the form
  99     <var>name</var>.example.com</li>
 100   <li>the example.com admin cannot create an entry for counterexample.com;
 101     only someone with authority for .com can do that</li>
 102   <li>an admin might have authority for 20.10.in-addr.arpa.</li>
 103   <li>in either map, authority can be delegated
 104     <ul>
 105       <li>the example.com admin could give you authority for
 106         westcoast.example.com</li>
 107       <li>the 20.10.in-addr.arpa admin could give you authority for
 108         30.20.10.in-addr.arpa</li>
 109     </ul>
 110   </li>
 111 </ul>
 112
 113 <p>DNS zones are the units of delegation. There is a hierarchy of zones.</p>
 114
 115 <h3>Syntax of DNS records</h3>
 116
 117 <p>Returning to the example records:</p>
 118 <pre>        gateway.example.com. IN A 10.20.30.40
 119         40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.</pre>
 120
 121 <p>some syntactic details are:</p>
 122 <ul>
 123   <li>the IN indicates that these records are for <strong>In</strong>ternet
 124     addresses</li>
 125   <li>The final periods in '.com.' and '.arpa.' are required. They indicate
 126     the root of the domain name system.</li>
 127 </ul>
 128
 129 <p>The capitalised strings after IN indicate the type of record. Possible
 130 types include:</p>
 131 <ul>
 132   <li><strong>A</strong>ddress, for forward lookups</li>
 133   <li><strong>P</strong>oin<strong>T</strong>e<strong>R</strong>, for reverse
 134     lookups</li>
 135   <li><strong>C</strong>anonical <strong>NAME</strong>, records to support
 136     aliasing, multiple names for one address</li>
 137   <li><strong>M</strong>ail e<strong>X</strong>change, used in mail
 138   routing</li>
 139   <li><strong>SIG</strong>nature, used in <a href="glossary.html#SDNS">secure
 140     DNS</a></li>
 141   <li><strong>KEY</strong>, used in <a href="glossary.html#SDNS">secure
 142     DNS</a></li>
 143   <li><strong>T</strong>e<strong>XT</strong>, a multi-purpose record type</li>
 144 </ul>
 145
 146 <p>To set up for opportunistic encryption, you add some KEY and TXT records
 147 to your DNS data. Details are in our <a href="quickstart.html">quickstart</a>
 148 document.</p>
 149
 150 <h3>Cacheing, TTL and propagation delay</h3>
 151
 152 <p>DNS information is extensively cached. With no caching, a lookup by your
 153 system of "www.freeswan.org" might involve:</p>
 154 <ul>
 155   <li>your system asks your nameserver for "www.freeswan.org"</li>
 156   <li>local nameserver asks root server about ".org", gets reply</li>
 157   <li>local nameserver asks .org nameserver about "freeswan.org", gets
 158   reply</li>
 159   <li>local nameserver asks freeswan.org nameserver about "www.freeswan.org",
 160     gets reply</li>
 161 </ul>
 162
 163 <p>However, this can be a bit inefficient. For example, if you are in the
 164 Phillipines, the closest a root server is in Japan. That might send you to a
 165 .org server in the US, and then to freeswan.org in Holland. If everyone did
 166 all those lookups every time they clicked on a web link, the net would grind
 167 to a halt.</p>
 168
 169 <p>Nameservers therefore cache information they look up. When you click on
 170 another link at www.freeswan.org, your local nameserver has the IP address
 171 for that server in its cache, and no further lookups are required. </p>
 172
 173 <p>Intermediate results are also cached. If you next go to
 174 lists.freeswan.org, your nameserver can just ask the freeswan.org nameserver
 175 for that address; it does not need to query the root or .org nameservers
 176 because it has a cached address for the freeswan.org zone server.</p>
 177
 178 <p>Of course, like any cacheing mechanism, this can create problems of
 179 consistency. What if the administrator for freeswan.org changes the IP
 180 address, or the authentication key, for www.freeswan.org? If you use old
 181 information from the cache, you may get it wrong. On the other hand, you
 182 cannot afford to look up fresh information every time. Nor can you expect the
 183 freeswan.org server to notify you; that isn't in the protocols.</p>
 184
 185 <p>The solution that is in the protocols is fairly simple. Cacheable records
 186 are marked with Time To Live (TTL) information. When the time expires, the
 187 caching server discards the record. The next time someone asks for it, the
 188 server fetches a fresh copy. Of course, a server may also discard records
 189 before their TTL expires if it is running out of cache space.</p>
 190
 191 <p>This implies that there will be some delay before the new version of a
 192 changed record propagates around the net. Until the TTLs on all copies of the
 193 old record expire, some users will see it because that is what is in their
 194 cache. Other users may see the new record immediately because they don't have
 195 an old one cached.</p>
 196
 197 <h2><a name="MTU.trouble">Problems with packet fragmentation</a></h2>
 198
 199 <p>It seems, from mailing list reports, to be moderately common for problems
 200 to crop up in which small packets pass through the IPsec tunnels just fine
 201 but larger packets fail.</p>
 202
 203 <p>These problems are caused by various devices along the way mis-handling
 204 either packet fragments or <a href="glossary.html#pathMTU">path MTU
 205 discovery</a>.</p>
 206
 207 <p>IPsec makes packets larger by adding an ESP or AH header. This can tickle
 208 assorted bugs in fragment handling in routers and firewalls, or in path MTU
 209 discovery mechanisms, and cause a variety of symptoms which are both annoying
 210 and, often, quite hard to diagnose.</p>
 211
 212 <p>An explanation from project technical lead Henry Spencer:</p>
 213 <pre>The problem is IP fragmentation; more precisely, the problem is that the
 214 second, third, etc. fragments of an IP packet are often difficult for
 215 filtering mechanisms to classify.
 216
 217 Routers cannot rely on reassembling the packet, or remembering what was in
 218 earlier fragments, because the fragments may be out of order or may even
 219 follow different routes.  So any general, worst-case filtering decision
 220 pretty much has to be made on each fragment independently.  (If the router
 221 knows that it is the only route to the destination, so all fragments
 222 *must* pass through it, reassembly would be possible... but most routers
 223 don't want to bother with the complications of that.)
 224
 225 All fragments carry roughly the original IP header, but any higher-level
 226 header is (for IP purposes) just the first part of the packet data... so
 227 only the first fragment carries that.  So, for example, on examining the
 228 second fragment of a TCP packet, you could tell that it's TCP, but not
 229 what port number it is destined for -- that information is in the TCP
 230 header, which appears in the first fragment only.
 231
 232 The result of this classification difficulty is that stupid routers and
 233 over-paranoid firewalls may just throw fragments away.  To get through
 234 them, you must reduce your MTU enough that fragmentation will not occur.
 235 (In some cases, they might be willing to attempt reassembly, but have very
 236 limited resources to devote to it, meaning that packets must be small and
 237 fragments few in number, leading to the same conclusion:  smaller MTU.)</pre>
 238
 239 <p>In addition to the problem Henry describes, you may also have trouble with
 240 <a href="glossary.html#pathMTU">path MTU discovery</a>.</p>
 241
 242 <p>By default, FreeS/WAN uses a large <a href="glossary.html#MTU">MTU</a> for
 243 the ipsec device. This avoids some problems, but may complicate others.
 244 Here's an explanation from Claudia:</p>
 245 <pre>Here are a couple of pieces of background information. Apologies if you
 246 have seen these already. An excerpt from one of my old posts:
 247
 248     An MTU of 16260 on ipsec0 is usual. The IPSec device defaults to this
 249     high MTU so that it does not fragment incoming packets before encryption
 250     and encapsulation. If after IPSec processing packets are larger than 1500,
 251     [ie. the mtu of eth0] then eth0 will fragment them.
 252
 253     Adding IPSec headers adds a certain number of bytes to each packet.
 254     The MTU of the IPSec interface refers to the maximum size of the packet
 255     before the IPSec headers are added. In some cases, people find it helpful
 256     to set ipsec0's MTU to 1500-(IPSec header size), which IIRC is about 1430.
 257
 258     That way, the resulting encapsulated packets don't exceed 1500. On most
 259     networks, packets less than 1500 will not need to be fragmented.
 260
 261 and... (from Henry Spencer)
 262
 263     The way it *ought* to work is that the MTU advertised by the ipsecN
 264     interface should be that of the underlying hardware interface, less a
 265     pinch for the extra headers needed.
 266
 267     Unfortunately, in certain situations this breaks many applications.
 268     There is a widespread implicit assumption that the smallest MTUs are
 269     at the ends of paths, not in the middle, and another that MTUs are
 270     never less than 1500.  A lot of code is unprepared to handle paths
 271     where there is an "interior minimum" in the MTU, especially when it's
 272     less than 1500. So we advertise a big MTU and just let the resulting
 273     big packets fragment.
 274
 275 This usually works, but we do get bitten in cases where some intermediate
 276 point can't handle all that fragmentation.  We can't win on this one.</pre>
 277
 278 <p>The MTU can be changed with an <var>overridemtu=</var> statement in the
 279 <var>config setup</var> section of <a
 280 href="manpage.d/ipsec.conf.5.html">ipsec.conf.5</a>.</p>
 281
 282 <p>For a discussion of MTU issues and some possible solutions using Linux
 283 advanced routing facilities, see the <a
 284 href="http://www.linuxguruz.org/iptables/howto/2.4routing-15.html#ss15.6">Linux
 285 2.4 Advanced Routing HOWTO</a>.</p>
 286
 287 <h2><a name="nat.background">Network address translation (NAT)</a></h2>
 288
 289 <p><strong>N</strong>etwork <strong>A</strong>ddress
 290 <strong>T</strong>ranslation is a service provided by some gateway machines.
 291 Calling it NAPT (adding the word  <strong>P</strong>ort) would be more
 292 precise, but we will follow the widespread usage.</p>
 293
 294 <p>A gateway doing NAT rewrites the headers of packets it is forwarding,
 295 changing one or more of:</p>
 296 <ul>
 297   <li>source address</li>
 298   <li>source port</li>
 299   <li>destination address</li>
 300   <li>destination port</li>
 301 </ul>
 302
 303 <p>On Linux 2.4, NAT services are provided by the <a
 304 href="http://netfilter.samba.org">netfilter(8)</a> firewall code. There are
 305 several <a
 306 href="http://netfilter.samba.org/documentation/index.html#HOWTO">Netfilter
 307 HowTos</a> including one on NAT.</p>
 308
 309 <p>For older versions of Linux, this was referred to as "IP masquerade" and
 310 different tools were used. See this <a
 311 href="http://www.e-infomax.com/ipmasq/">resource page</a>.</p>
 312
 313 <p>Putting an IPsec gateway behind a NAT gateway is not recommended. See our
 314 <a href="firewall.html#NAT">firewalls document</a>.</p>
 315
 316 <h3>NAT to non-routable addresses</h3>
 317
 318 <p>The most common application of NAT uses private <a
 319 href="glossary.html#non-routable">non-routable</a> addresses.</p>
 320
 321 <p>Often a home or small office network will have:</p>
 322 <ul>
 323   <li>one connection to the Internet</li>
 324   <li>one assigned publicly visible IP address</li>
 325   <li>several machines that all need access to the net</li>
 326 </ul>
 327
 328 <p>Of course this poses a problem since several machines cannot use one
 329 address. The best solution might be to obtain more addresses, but often this
 330 is impractical or uneconomical.</p>
 331
 332 <p>A common solution is to have:</p>
 333 <ul>
 334   <li><a href="glossary.html#non-routable">non-routable</a> addresses on the
 335     local network</li>
 336   <li>the gateway machine doing NAT</li>
 337   <li>all packets going outside the LAN rewritten to have the gateway as
 338     their source address</li>
 339 </ul>
 340
 341 <p>The client machines are set up with reserved <a
 342 href="#non-routable">non-routable</a> IP addresses defined in RFC 1918. The
 343 masquerading gateway, the machine with the actual link to the Internet,
 344 rewrites packet headers so that all packets going onto the Internet appear to
 345 come from one IP address, that of its Internet interface. It then gets all
 346 the replies, does some table lookups and more header rewriting, and delivers
 347 the replies to the appropriate client machines.</p>
 348
 349 <p>As far as anyone else on the Internet is concerned, the systems behind the
 350 gateway are completely hidden. Only one machine with one IP address is
 351 visible.</p>
 352
 353 <p>For IPsec on such a gateway, you can entirely ignore the NAT in:</p>
 354 <ul>
 355   <li><a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a></li>
 356   <li>firewall rules affecting your Internet-side interface</li>
 357 </ul>
 358
 359 <p>Those can be set up exactly as they would be if your gateway had no other
 360 systems behind it.</p>
 361
 362 <p>You do, however, have to take account of the NAT in firewall rules which
 363 affect packet forwarding.</p>
 364
 365 <h3>NAT to routable addresses</h3>
 366
 367 <p>NAT to routable addresses is also possible, but is less common and may
 368 make for rather tricky routing problems. We will not discuss it here. See the
 369 <a href="http://netfilter.samba.org/documentation/index.html#HOWTO">Netfilter
 370 HowTos</a>.</p>
 371 </body>
 372 </html>