freeswan/klips/doc/ji_setup.txt

   1 *
   2 * RCSID $Id: ji_setup.txt,v 1.6 1999/04/06 04:54:23 rgb Exp $
   3 *
   4
   5 [Here is JI's setup.  This document is OBSOLETE (rgb, May 6, 1998) but is
   6 included for historical purposes and the concepts are still relevant
   7 although commands and syntax have changed significantly.
   8
   9 Here is a simplified view of JI's testbed:
  10
  11
  12     +-------+                                               +-------+
  13     |  elf  |                                               |  del  |
  14     +---*---+                                               +---*---+
  15    eth1 * 10.1.0.145                                        ef1 * 10.3.0.140
  16         *                                                       *
  17     *************************               *************************
  18                         *                       *
  19                    eth1 * 10.1.0.143       eth2 * 10.3.0.139
  20                     +---*---+               +---*---+
  21                     |  fir  |               |  ice  |
  22                     +---*---+               +---*---+
  23                    eth2 * 10.2.0.143       eth1 * 10.2.0.139
  24                         *                       *
  25                     *********************************
  26
  27
  28 In case you are wondering, all machines are connected to the same
  29 "main" network with their eth0 interfaces, but this is irrelevant to
  30 the examples, and hence not shown in the diagram.
  31
  32 Only fir and ice need to run IPSEC.
  33
  34 All netmasks are 255.255.0.0.
  35
  36 Elf has a route to 10.3.xx.xx via fir, and del has a route to
  37 10.1.xx.xx via ice.
  38
  39 fir and ice know how to route only to their connected subnets; fir
  40 does not (yet) know how to get to 10.3.xx.xx, and ice does not know how to
  41 get to 10.1.xx.xx.
  42
  43 First, let us set up fir.
  44
  45
  46 Now, ipsec0 needs to be associated with a real interface. In our case,
  47 we shall associate it with the interface on the 10.2.0.0 subnet, that
  48 is, eth2, because that's where IPSEC'ed traffic will flow. Then we
  49 need to configure the new pseudo interface. Because
  50 there is already a route to subnet 10.2.0.0 using eth2, we also need
  51 to remove than and let the ipsec0 interface handle it:
  52
  53         fir# tncfg attach ipsec0 eth2
  54         fir# ifconfig ipsec0 10.2.0.143 netmask 255.255.0.0
  55         fir# route del 10.2.0.0
  56         fir# route add -net 10.2.0.0 netmask 255.255.0.0 dev ipsec0
  57
  58 On ice, just load the module.
  59
  60 2.1. Transport Mode.
  61
  62 Let us have fir and ice communicate securely, using the latest and
  63 greatest IPSEC transform: triple-DES with replay protection and
  64 96-bits of MD5 hash.
  65
  66 Issue the following command, which tells fir to process packets
  67 originating with it and destined for ice by applying a transform
  68 defined by destination address 10.2.0.139 (ice) and SPI 125
  69
  70         fir# addrt 10.2.0.143 255.255.255.255 10.2.0.139 255.255.255.255 \
  71                 10.2.0.139 125
  72
  73 To verify it has worked, type:
  74
  75         fir# cat /proc/net/ipsec-rt
  76
  77 you should get:
  78
  79         (10.2.0.143/255.255.255.255 -> 10.2.0.139/255.255.255.255) =>
  80                 (10.2.0.139, 0x00000115)
  81
  82 To set the actual Security Association, type:
  83
  84         fir# setsa 10.2.0.139 125 esp 3des-md5-96 i \
  85                  1000000000000001 6630663066303132
  86
  87 And type the same thing on ice, so it will know how to decrypt packets:
  88
  89         ice# setsa 10.2.0.139 125 esp 3des-md5-96 i \
  90                  1000000000000001 6630663066303132
  91
  92 If you ping ice from fir, and look at the traffic on the wire, you'll
  93 see that packets from fir to ice are encrypted (and authenticated),
  94 while packets from ice to fir are in the clear. Needless to say, you
  95 can set up a symmetric set of transforms on ice and fir,
  96 repspectively, so that the reverse traffic is also encrypted.
  97
  98 2.2. Tunnel mode.
  99
 100 Now, we want to set up fir so that packets from elf to del will be
 101 tunneled through the (fir->ice) tunnel. The first step is to set up a
 102 route to net 10.3.xx.xx through the ipsec0 interface:
 103
 104
 105         fir# route add -net 10.3.0.0 netmask 255.255.0.0 dev ipsec0 gw
 106 10.2.0.139
 107
 108 [ To understand what this does, remember that we "attached" eth2 to
 109 ipsec0; the route is set up so that packets will be routed through
 110 ice, but they will first pass through the ipsec0 interface; then, when
 111 they have been processed, they will be passed on to the attached
 112 interface and delivered to the next-hop specified in the gw parameter
 113 in the route command. ]
 114
 115 Now, issue the following command:
 116
 117         fir# addrt 10.1.0.0 255.255.0.0 10.3.0.0 255.255.0.0 10.2.0.139 103
 118
 119 To verify it has worked, type:
 120
 121         fir# cat /proc/net/ipsec-rt
 122
 123 you should get:
 124
 125 (10.1.0.0/255.255.0.0 -> 10.3.0.0/255.255.0.0) => (10.2.0.139, 0x00000103)
 126
 127
 128 This means that packets originating from net 10.1.xx.xx and destined
 129 for net 10.3.xx.xx should be IPSEC-processed, with a "Destination
 130 Address" of 10.2.0.139 and a "Security Parameters Index" of 103. The
 131 Destination Address indicates the other point of the tunnel, whether
 132 it is a real tunnel (as in this case), or simply the destination (in
 133 what we call "transport mode" which doesn't quite work yet). The
 134 Security Parameters Index, or SPI, is an opaque value that indicates,
 135 along with the DA, what processing these packets will receive at our
 136 end as well as the remote end. The pair (DA, SPI) is called a SAID
 137 (Security Association IDentifier) in this document.
 138
 139 We now want to tell the IPSEC code what the processing for packets
 140 which have been selected to be processed with DA=10.2.0.139 and
 141 SPI=103. First, they will be encapsulated in simple IP-in-IP (proto 4)
 142 encapsulation, and to enable that we type:
 143
 144         fir# setsa 10.2.0.139 103 ip4 10.2.0.143 10.2.0.139
 145
 146 This tells the IPSEC code that packets which have been selected to be
 147 processed with DA=10.2.0.139 and SPI=103 should be run through algorithm
 148 1 (IP-in-IP), with "outer" (encapsulating packet) source and
 149 destination addresses of 10.2.0.143 (fir) and 10.2.0.139 (ice)
 150 respectively. Type
 151
 152         fir# cat /proc/net/ipsec-spi
 153
 154 to verify that the SAID has been formed. You should get
 155
 156 (10.2.0.139, 00000103, 1: [10.2.0.143 -> 10.2.0.139])
 157
 158 So far so good, but we've simply reproduced already existing
 159 functionality. Now, let's add security. First, we'll tell the code to
 160 encrypt packets using the ESP-DES-CBC transform. We'll create another
 161 SAID, this time for algorithm 4 (ESP-DES-CBC).
 162
 163         fir# setsa 10.2.0.139 105 esp des-cbc 66306630 6630663066303132
 164
 165 This tells the IPSEC layer that packets destined to be processed with
 166 DA=10.2.0.139, SPI=105, should be processed with algorithm #4
 167 (ESP-DES-CBC), use 0x66306630 as the DES-CBC Initialization Vector,
 168 and use 0x6630663066303132 as the DES key (the DES parity bits are
 169 ignored, so this yields the 56-bit DES key).
 170
 171 Finally, we also want to authenticate the resulting packet, so we
 172 create another SAID, this time for the AH-MD5 transform:
 173
 174         fir# setsa 10.2.0.139 106 ah md5 66306630663031326630663066303132
 175
 176 Now comes the crucial step. What the original addrt command did was to
 177 establish that outgoing packets are to be processed with IP-in-IP
 178 encapsulatino first. Now, we need to "link" this transform (IPIP) to the ESP
 179 transform and then the AH. We do that with the spigrp ("group SPIs")command:
 180
 181         fir# spigrp 10.2.0.139 103 10.2.0.139 105 10.2.0.139 106
 182
 183 Now, we also need to specify what will happen when we receive
 184 packets. IP-in-IP does not need any special handling. ESP and AH,
 185 however, need the SAIDs to be established. We use the same commands we
 186 used for the outgoing packets, but specifying ourselves as the
 187 destination (of course).
 188
 189         fir# setsa 10.2.0.143 115 esp des-cbc 66306630 6630663066303132
 190         fir# setsa 10.2.0.143 116 ah md5 66306630663031326630663066303132
 191
 192 To see the whole picture, type:
 193         fir# cat /proc/net/ipsec-spi
 194         (10.2.0.143, 00000116, 2: klen = 16, alen = 16)
 195         (10.2.0.143, 00000115, 4: ivlen = 4, iv = 66 30 66 30)
 196         (10.2.0.139, 00000106, 2: klen = 16, alen = 16)
 197         (10.2.0.139, 00000105, 4: ivlen = 4, iv = 66 30 66 30)
 198         (10.2.0.139, 00000103, 1: [10.2.0.143 -> 10.2.0.139])
 199
 200 On ice, now, we have to send things up the opposite way. Here are the
 201 commands to use:
 202
 203         ice# ifconfig ipsec0 10.2.0.139 netmask 255.255.0.0
 204         ice# route add -net 10.1.0.0 netmask 255.255.0.0 dev ipsec0
 205
 206         ice# addrt 10.3.0.0 255.255.0.0 10.1.0.0 255.255.0.0 10.2.0.143 113
 207         ice# setsa 10.2.0.143 113 ip4 10.2.0.139 10.2.0.143
 208         ice# setsa 10.2.0.143 115 esp des-cbc 66306630 6630663066303132
 209         ice# setsa 10.2.0.143 116 ah md5 66306630663031326630663066303132
 210
 211         ice# spigrp 10.2.0.143 113 10.2.0.143 115 10.2.0.143 116
 212
 213         ice# setsa 10.2.0.139 105 esp des-cbc 66306630 6630663066303132
 214         ice# setsa 10.2.0.139 106 ah md5 66306630663031326630663066303132
 215
 216         ice# cat /proc/net/ipsec-rt
 217         (10.3.0.0/255.255.0.0 -> 10.1.0.0/255.255.0.0) => (10.2.0.143, 0x00000113)
 218         ice# cat /proc/net/ipsec-spi
 219         (10.2.0.143, 00000116, 2: klen = 16, alen = 16)
 220         (10.2.0.143, 00000115, 4: ivlen = 4, iv = 6f 30 66 30)
 221         (10.2.0.143, 00000113, 1: [10.2.0.139 -> 10.2.0.143])
 222         (10.2.0.139, 00000106, 2: klen = 16, alen = 16)
 223         (10.2.0.139, 00000105, 4: ivlen = 4, iv = 66 30 66 30)
 224
 225 If you ping del from elf, ICMP packets will leave elf, reach fir, get
 226 encapsulated in IPIP, encrypted with DES and authenticated with MD5,
 227 tunneled to ice, get decapsulated, and then sent to del; the return
 228 packets will follow the inverse path.
 229
 230 For completeness, let us show part of the routing tables on all four machines:
 231
 232 fir# netstat -r -n
 233 Kernel routing table
 234 Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
 235 <my-home-net>   0.0.0.0         255.255.255.128 U     0      0       32 eth0
 236 10.1.0.0        0.0.0.0         255.255.0.0     U     0      0        2 eth1
 237 10.2.0.0        0.0.0.0         255.255.0.0     U     0      0        3 eth2
 238 10.3.0.0        0.0.0.0         255.255.0.0     U     0      0        2 ipsec0
 239 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        4 lo
 240
 241 ice# netstat -r -n
 242 Kernel routing table
 243 Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
 244 <my-home-net>   0.0.0.0         255.255.255.128 U     0      0       10 eth0
 245 10.2.0.0        0.0.0.0         255.255.0.0     U     0      0        1 eth1
 246 10.3.0.0        0.0.0.0         255.255.0.0     U     0      0        2 eth2
 247 10.1.0.0        0.0.0.0         255.255.0.0     U     0      0        1 ipsec0
 248 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        1 lo
 249
 250 elf$ netstat -r -n
 251 Kernel routing table
 252 Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
 253 <my-home-net>   0.0.0.0         255.255.255.128 U     0      0       11 eth0
 254 10.1.0.0        0.0.0.0         255.255.0.0     U     0      0        1 eth1
 255 10.3.0.0        10.1.0.143      255.255.0.0     UG    0      0        1 eth1
 256 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        1 lo
 257
 258 del$ netstat -r -n
 259 <...>
 260 Destination      Gateway            Flags     Refs     Use  Interface
 261 10.1/16          10.3.0.139         UGS         0      613  ne1
 262 10.3/16          link#1             UC          0        0  ne1
 263 <...>
 264
 265 (del is a BSD machine).
 266
 267
 268 *
 269 * $Log: ji_setup.txt,v $
 270 * Revision 1.6  1999/04/06 04:54:23  rgb
 271 * Fix/Add RCSID Id: and Log: bits to make PHMDs happy.  This includes
 272 * patch shell fixes.
 273 *
 274 *