]>
Commit | Line | Data |
---|---|---|
997358a6 MW |
1 | FreeS/WAN Opportunism HowTo |
2 | =========================== | |
3 | ||
4 | RCSID $Id: opportunism.howto,v 1.1 2004/03/15 20:35:21 as Exp $ | |
5 | ||
6 | D. Hugh Redelmeier | |
7 | ||
8 | ||
9 | FreeS/WAN, the LINUX IPSEC implementation, is intended to allow | |
10 | systems to connect through secure tunnels with or without prearrangement. | |
11 | We use the term "Opportunism" to describe tunnels set up without | |
12 | prearrangement. This HowTo will show you how to set your system up | |
13 | for Opportunism. | |
14 | ||
15 | You are expected to already have built and used FreeS/WAN. Much more | |
16 | information about FreeS/WAN is provided at http://www.freeswan.org. | |
17 | This document is only intended to describe the support for | |
18 | opportunism. The features described here are available in FreeS/WAN | |
19 | version 1.91 or later (there were important bugs up until 1.95). | |
20 | ||
21 | For a more complete description of the design of Opportunism, see our | |
22 | paper "Opportunistic Encryption" (available as opportunism.spec in | |
23 | the same directory as this document). | |
24 | ||
25 | ||
26 | Steps | |
27 | ===== | |
28 | ||
29 | - Understand what you are attempting. Security requires care. | |
30 | Problems are hard to untangle. Be sure to read the last section | |
31 | "Important Limitations". | |
32 | ||
33 | - Install FreeS/WAN (version 1.91 or later). | |
34 | ||
35 | - Add appropriate DNS records to your reverse-map domains. | |
36 | ||
37 | - Add suitable conns to /etc/ipsec.conf. | |
38 | ||
39 | - Try it out: start it, monitor it, fix it. | |
40 | ||
41 | - Now you understand the system better, reread "Important Limitations" | |
42 | ||
43 | These steps are also an outline of this document. | |
44 | ||
45 | ||
46 | Theory | |
47 | ====== | |
48 | ||
49 | FreeS/WAN runs on a machine that we will call a "Security Gateway". | |
50 | Usually this machine is a gateway to the internet. It may be that the | |
51 | only machine for which it provides gateway services is itself, but | |
52 | that is just a special case -- we will still call it a Security | |
53 | Gateway. | |
54 | ||
55 | A FreeS/WAN Security Gateway implements secure tunnels to other | |
56 | Security Gateways. One problem is to arrange for these tunnels to be | |
57 | created and used. If opportunism is enabled, a Security Gateway | |
58 | running FreeS/WAN will intercept the first outbound packet to a | |
59 | particular destination (IP address), and try to negotiate a security | |
60 | tunnel suitable for traffic to that destination. | |
61 | ||
62 | To make this work going the other way, the Security Gateway must be | |
63 | willing to negotiate with peers trying to protect traffic initiated | |
64 | from their side. | |
65 | ||
66 | The first novel problem is that our Security Gateway needs to discover | |
67 | the IP address of the other Security Gateway for the packet that | |
68 | prompted the negotiation. Oh, and quickly discover if there is none | |
69 | -- that negotiation will be impossible. | |
70 | ||
71 | The second novel problem is that our Security Gateway needs to | |
72 | authenticate the other Security Gateway. This authentication needs to | |
73 | ensure that the other Security Gateway is who it claims to be AND that | |
74 | it is authorized to represent the client for which it claims to be the | |
75 | gateway. | |
76 | ||
77 | The roles in a particular negotiation are: | |
78 | Source----Initiator----...----Responder----Destination | |
79 | ||
80 | The Source and Destination are endpoints of the traffic that is to be | |
81 | protected. The Source is the one that happened to send the first | |
82 | packet of traffic. Neither needs to be aware of IPSEC or FreeS/WAN. | |
83 | That is the job of their respective Security Gateways, Initiator and | |
84 | Responder. The names "Initiator" and "Responder" match those used in | |
85 | the IPSEC standards for IKE negotiation. Remember that Source and | |
86 | Initiator could be the same machine; similarly, Destination and | |
87 | Responder could be the same. All traffic from Source or Destination | |
88 | must flow through their Security Gateways if it is to be considered | |
89 | for protection. These roles are fluid -- they can be different for | |
90 | each negotiation. | |
91 | ||
92 | We use the DNS (the Domain Name System) as a distributed database to | |
93 | publish the required information. | |
94 | ||
95 | ||
96 | DNS Records Required | |
97 | ==================== | |
98 | ||
99 | See section 2.3 of "Opportunistic Encryption" for a fuller | |
100 | explanation. | |
101 | ||
102 | Generally, we need to add records to the reverse-map DNS entries for | |
103 | the client machine and its Security Gateway machine. There are | |
104 | special cases that are exceptions. | |
105 | ||
106 | A Security Gateway that is going to initiate an Opportunistic | |
107 | negotiation needs to provide a way for the Responding SG to find a | |
108 | public key for the Initiator to allow authentication. This is | |
109 | accomplished by putting the public key in a KEY record in the | |
110 | reverse-map of the Initiator. Conveniently, the KEY record can | |
111 | be generated by the ipsec_showhostkey(8) command. | |
112 | ||
113 | ipsec showhostkey | |
114 | ||
115 | Here is an example of the output, with many characters of the key | |
116 | itself left out: | |
117 | ||
118 | ; RSA 2048 bits xy.example.com Sat Apr 15 13:53:22 2000 | |
119 | xy.example.com. IN KEY 0x4200 4 1 AQOF8tZ2...+buFuFn/ | |
120 | ||
121 | => Copy the output of the command into the zone information for the | |
122 | reverse-map of the Security Gateway's public interface. | |
123 | ||
124 | Each client that is to be protected by Opportunistic Encryption must | |
125 | include a special TXT record in its reverse-map. The | |
126 | ipsec_showhostkey(8) command can create this too. Remember: this | |
127 | command must be run on the Security Gateway where the ipsec.secrets | |
128 | file resides. You must tell the command what IP address to put in the | |
129 | TXT record. The IP address is that of the Security Gateway. | |
130 | ||
131 | ipsec showhostkey --txt 10.11.12.13 | |
132 | ||
133 | This command might produce the output: | |
134 | ||
135 | ; RSA 2048 bits xy.example.com Sat Apr 15 13:53:22 2000 | |
136 | IN TXT "X-IPsec-Server(10)=10.11.12.13 AQOF8tZ2...+buFuFn/" | |
137 | ||
138 | - The quotes matter: this is a single string, as far as DNS is | |
139 | concerned. | |
140 | ||
141 | - The X-IPsec-Server is a prefix that signifies that the TXT record | |
142 | contains Opportunism configuration information. | |
143 | ||
144 | - The (10) specifies a precedence for this record. This is similar | |
145 | to MX record preferences. Lower numbers have stronger preference. | |
146 | ||
147 | - 10.11.12.13 specifies the IP address of the Security Gateway for | |
148 | this machine. | |
149 | ||
150 | - AQOF8tZ2...+buFuFn/ is the (shortened) encoding of the RSA Public | |
151 | key of the Security Gateway. | |
152 | ||
153 | => Added this output to the zone information for the reverse-map for | |
154 | each client machine. This gets a bit dull and repetitive. | |
155 | ||
156 | Unfortunately, not every administrator has control over the contents | |
157 | of the reverse-map. The only case where we can work around this is | |
158 | where the Initiator has no suitable reverse map. In this case, the | |
159 | Source's TXT record gives @FQDN ("Fully Qualified Domain Name") in | |
160 | place of its Security Gateway's IP address. This FQDN must match the | |
161 | ID-payload used by the Initiator. Furthermore, a forward lookup for a | |
162 | KEY record on the FQDN must yield the Initiator's public key. | |
163 | ||
164 | If the Source's IP address is the same as the Initiator's IP address, | |
165 | the Responder will assume that the Initiator is authorized to talk for | |
166 | the Source (itself!). In this case, the Responder won't try to fetch | |
167 | the Source's TXT record from the reverse map for the Source's IP | |
168 | address. | |
169 | ||
170 | These two features can be combined. If the Source and the Initiator | |
171 | are the same (i.e. the Security Gateway is protecting itself), and the | |
172 | Initiator uses a @FQDN ID (leftid=@example.com), then the | |
173 | administrator of that machine need only have installed a KEY record in | |
174 | the FQDN domain -- he need not control any reverse map. | |
175 | ||
176 | Obscure fact: the forward lookup is only done by a Responder, and then | |
177 | only when the Initiator's ID payload specifies the FQDN. There is no | |
178 | provision for a Responder with no control over its reverse-map. | |
179 | ||
180 | Beware: DNS changes sometimes take a long time to propagate. | |
181 | ||
182 | ||
183 | Configuring FreeS/WAN | |
184 | ===================== | |
185 | ||
186 | To enable opportunism, you must include a suitable conn in | |
187 | /etc/ipsec.conf and you must enable it. | |
188 | ||
189 | A suitable conn looks roughly like an ordinary conn. It more closely | |
190 | resembles a Road Warrior conn (a Road Warrior conn is one that has a | |
191 | wildcard %any specified as the other Security Gateway). But in the | |
192 | Opportunistic case, both the other Security Gateway AND its client are | |
193 | unknown ahead of time. | |
194 | ||
195 | conn client-to-anyone # for our client subnet | |
196 | leftsubnet=10.3.2.1.0/24 # any single client in our subnet | |
197 | also=sg-to-anyone # rest is same as for SG | |
198 | ||
199 | conn sg-to-anyone # for our Security Gateway | |
200 | left=%defaultroute # our SG (defaults leftnexthop too) | |
201 | right=%opportunistic | |
202 | authby=rsasig # almost always the right choice | |
203 | keyingtries=2 # don't be persistent -- peer might disappear | |
204 | auto=route # enable at ipsec startup | |
205 | ||
206 | (%defaultroute only works if you have specified | |
207 | interfaces=%defaultroute. Since this isn't the topic of the howto, | |
208 | you will have to look at the other documentation to find out how to | |
209 | handle other cases.) | |
210 | ||
211 | You can have any number of opportunistic conns, but generally it only | |
212 | makes sense to have one for each client subnet and one for the | |
213 | Security Gateway itself. | |
214 | ||
215 | Currently only one interface may be used for opportunism: Pluto knows | |
216 | nothing about routing, so would be unable to choose amongst several. | |
217 | Almost certainly our side's nexthop must be predetermined | |
218 | (%defaultroute will do that). | |
219 | ||
220 | Note: the routing done for outbound Opportunism will catch any packets | |
221 | not covered by a more specific route. This is what you want for | |
222 | packets that are also covered by an eroute. But packets caught by the | |
223 | route and not an eroute will be subject to the no-eroute policy of | |
224 | KLIPS, which defaults to %drop. Remember that routing ignores the | |
225 | packet's source address, but erouting pays attention to it. So if | |
226 | Opportunism is enabled, it is best to provide for it covering all IP | |
227 | addresses behind or on the Security Gateway. | |
228 | ||
229 | To enable these conns for inbound opportunistic negotiation, they must be | |
230 | --added. auto=add would accomplish this at ipsec startup, but if you cannot | |
231 | wait: | |
232 | ipsec auto --add sg-to-anyone | |
233 | ipsec auto --add client-to-anyone | |
234 | ||
235 | To enable these conns for outbound opportunistic negotiation, they must | |
236 | be both --added and --routed. Outbound packets will then be trapped | |
237 | and will trigger negotiation. auto=route would cause this to happen | |
238 | at startup, but if you wish to do this at another time: | |
239 | ipsec auto --add sg-to-anyone | |
240 | ipsec auto --add client-to-anyone | |
241 | ipsec auto --route sg-to-anyone | |
242 | ipsec auto --route client-to-anyone | |
243 | ||
244 | ||
245 | Getting DNS Through | |
246 | =================== | |
247 | ||
248 | There is a serious chicken-and-egg problem. Outbound Opportunism blocks | |
249 | communication with an IP address until Pluto discovers whether that IP | |
250 | address can have an IPSEC connection negotiated. This discovery takes | |
251 | DNS queries. These DNS queries might involve communicating with | |
252 | arbitrary IP addresses. Thus we require DNS queries to succeed before | |
253 | any communication succeeds, including those same DNS queries! The way | |
254 | out of this conundrum is to exempt at least some DNS query IP traffic | |
255 | from Opportunism. | |
256 | ||
257 | There are several possible solutions, all of which have advantages and | |
258 | disadvantages. | |
259 | ||
260 | 1. If you use a single machine, outside your Security Gateway, as DNS | |
261 | server, you can build a clear path (or even an IPSEC tunnel, but not | |
262 | opportunistically) directly to that machine. | |
263 | ||
264 | - you could use a type=passthrough conn to provide a clear path | |
265 | between your machine and the DNS machine. | |
266 | ||
267 | - better still, you could explicitly create an IPSEC connection to | |
268 | your DNS server. Just be sure that Pluto does not need to access | |
269 | DNS to find the IP addresses or RSA public keys for that connection! | |
270 | ||
271 | - you could install an explicit route to the DNS machine through | |
272 | your public interface (not ipsecN). This will bypass KLIPS | |
273 | processing. You might have to adjust your firewall. For example: | |
274 | ||
275 | route add host -net ns.example.com gw gw.example.com dev eth1 | |
276 | ||
277 | 2. Generally, it is better to run DNS on your Security Gateway. This | |
278 | leads to a need for non-opportunistic paths to an arbitrary number of | |
279 | DNS servers in the internet. One way to accomplish this is to NOT | |
280 | have outbound opportunism cover the SG itself, but only the subnet | |
281 | behind it. In other words, leave out the | |
282 | ipsec auto --route sg-to-anyone | |
283 | You must also add a type=passthrough eroute specifically for | |
284 | sg-to-anyone (without this, the traffic will be handled by the KLIPS | |
285 | no-eroute policy). | |
286 | ||
287 | 3. It is actually possible to use a single machine inside your client | |
288 | subnet as a DNS server. The techniques listed in 1 could be used to | |
289 | let it communicate with other DNS servers without interference. This | |
290 | might have advantages over 1 if the DNS machine *only* did DNS. | |
291 | Another technique (not often possible or reasonable) is to give this | |
292 | machine another route to the internet, one that avoids the SG. | |
293 | ||
294 | 4. DNS queries will eventually time out and then Pluto will give up | |
295 | and establish %pass eroutes. So communications should start flowing. | |
296 | ||
297 | We would like to have better solutions. Perhaps we will in the | |
298 | future. Suggestions are welcome. | |
299 | ||
300 | ||
301 | Figuring out what is going on | |
302 | ============================= | |
303 | ||
304 | Since Opportunism lets your SG operate with less supervision, you may | |
305 | be puzzled by what it is up to. The usual tools exist, but their use | |
306 | is more important. To look at what Pluto is doing, use: | |
307 | ipsec auto --status | |
308 | To look at what KLIPS is doing, use | |
309 | ipsec look | |
310 | ||
311 | To just see the kernel's eroute table, look at the "file" | |
312 | /proc/net/ipsec_eroute. It contains a description of all the eroutes | |
313 | in the kernel. Here is an example: | |
314 | ||
315 | 10 10.2.1.0/24 -> 0.0.0.0/0 => %trap | |
316 | 259 10.2.1.115/32 -> 10.19.75.161/32 => tun0x1002@10.19.75.145 | |
317 | 71 10.44.73.97/32 -> 0.0.0.0/0 => %trap | |
318 | 4119 10.44.73.97/32 -> 10.114.121.41/32 => %pass | |
319 | ||
320 | You read each line as: a packet from within the first subnet, destined | |
321 | for the second subnet, will be processed by the Security Association | |
322 | Identity (SAID) specified last. The first column is the number of | |
323 | (outbound) packets processed by this eroute. | |
324 | ||
325 | For shunt eroutes, the SAID is printed as just the type of shunt: | |
326 | %pass pass the packet through with no processing | |
327 | %drop discard the packet | |
328 | %reject discard the packet and notify sender | |
329 | %hold keep the last packet; discard others | |
330 | %trap cause any trapped packet to generate a PF_KEY ACQUIRE | |
331 | to request negotiation; install a corresponding %hold | |
332 | shunt and attach this packet to the %hold | |
333 | ||
334 | For other eroutes, the SAID is printed as a triple: protocol (three | |
335 | letters), SPI (32-bit number in hex), and destination IP address. | |
336 | Protocols include: | |
337 | ||
338 | tun IP in IP encapsulation (used for most tunnels) | |
339 | esp ESP encapsulation -- part of an IPSEC SA group | |
340 | ah AH packet authentication -- part of an IPSEC SA group | |
341 | ||
342 | So, looking at our sample eroutes: | |
343 | ||
344 | 10 10.2.1.0/24 -> 0.0.0.0/0 => %trap | |
345 | ||
346 | This is a TRAP (int0x104) shunt eroute. It was installed by | |
347 | Pluto so that it can catch all traffic from its client subnet | |
348 | to the world at large. Ten outbound packets have been trapped. | |
349 | ||
350 | 259 10.2.1.115/32 -> 10.19.75.161/32 => tun0x1002@10.19.75.145 | |
351 | ||
352 | This is a tunnel eroute: packets from 10.2.1.115 (within | |
353 | our client subnet) going to 10.19.75.161 will be encrypted | |
354 | and sent to the peer SG 10.19.75.145. This was the product | |
355 | of an Opportunistic negotiation (a hint is that each client | |
356 | subnet has only one member). 259 packets have been sent | |
357 | through this tunnel. | |
358 | ||
359 | 71 10.44.73.97/32 -> 0.0.0.0/0 => %trap | |
360 | ||
361 | This is another TRAP shunt eroute. It is to catch traffic | |
362 | from the Security Gateway to the world. It has caught | |
363 | 71 outbound packets. | |
364 | ||
365 | 4119 10.44.73.97/32 -> 10.114.121.41/32 => %pass | |
366 | ||
367 | This is a %pass (0x100) shunt eroute. It was installed when an | |
368 | attempted Opportunistic negotiation failed because the reverse | |
369 | domain of 10.114.121.41 had no suitable TXT record. 4119 | |
370 | outbound packets have been passed. | |
371 | ||
372 | ||
373 | Important Limitations | |
374 | ===================== | |
375 | ||
376 | Pluto's DNS lookup is synchronous (single-threaded). Not only does | |
377 | this slow things down, but it turns out that in extreme cases where | |
378 | there are a lot of ACQUIRE messages from KLIPS at once, some of those | |
379 | messages can be lost and communications will be blocked by the %hold | |
380 | eroute that Pluto doesn't know about. Pluto now looks every 2 minutes | |
381 | for any %holds that it missed. | |
382 | ||
383 | DNS lookup is not verified -- we don't use Secure DNS. A spoofed DNS | |
384 | could compromise Opportunism. | |
385 | ||
386 | There are several new opportunities for Denial of Service attacks. | |
387 | For example, a Bad Guy could spray our system with pings with forged | |
388 | source addresses. For each unique source address, our system would do | |
389 | a (synchronous!) DNS lookup. | |
390 | ||
391 | Once a %pass eroute is added for a failed negotiation, it will stay | |
392 | until it has been inactive for about 15 minutes. The only activity | |
393 | that counts is outbound -- not surprising since a %pass only affects | |
394 | outbound traffic. | |
395 | ||
396 | If a destination's DNS entry specifies the information we need for | |
397 | negotiation, Pluto will not let communications proceed without | |
398 | negotiating a Security Tunnel. | |
399 | ||
400 | There is currently no way to tear down a tunnel that is no longer in | |
401 | use. To add insult to injury, when the lifetime is about to be | |
402 | exceeded, the initiating Pluto will rekey! Restarting will clear | |
403 | these out. rekey=no doesn't solve this since SA expiry would be | |
404 | uncoordinated and hence cause packets to be lost. | |
405 | ||
406 | If one side of a Security Tunnel restarts, but doesn't initiate | |
407 | negotiation with its peer, the peer will not be able to communicate | |
408 | with it until the peer thinks the tunnel needs rekeying due to | |
409 | lifetime, or the restarted Security Gateway decides to negotiate for | |
410 | its own reasons. | |
411 | ||
412 | It isn't clear what firewall policies make sense with Opportunism. | |
413 | ||
414 | If VPN and Opportunism connections coexist, security policies | |
415 | implemented via a firewall can only distinguish traffic by IP address. |