]>
Commit | Line | Data |
---|---|---|
997358a6 MW |
1 | Implementing Opportunistic Encryption |
2 | ||
3 | Henry Spencer & D. Hugh Redelmeier | |
4 | ||
5 | Version 4+, 15 Dec 2000 | |
6 | ||
7 | ||
8 | ||
9 | Updates | |
10 | ||
11 | Major changes since last version: "Negotiation Issues" section discussing | |
12 | some interoperability matters, plus some wording cleanup. Some issues | |
13 | arising from discussions at OLS are not yet resolved, so there will almost | |
14 | certainly be another version soon. | |
15 | ||
16 | xxx incoming could be opportunistic or RW. xxx any way of saving unaware | |
17 | implementations??? xxx compression needs mention. | |
18 | ||
19 | ||
20 | ||
21 | Introduction | |
22 | ||
23 | A major long-term goal of the FreeS/WAN project is opportunistic | |
24 | encryption: a security gateway intercepts an outgoing packet aimed at a | |
25 | new remote host, and quickly attempts to negotiate an IPsec tunnel to that | |
26 | host's security gateway, so that traffic can be encrypted and | |
27 | authenticated without changes to the host software. (This generalizes | |
28 | trivially to the end-to-end case where host and security gateway are one | |
29 | and the same.) If the attempt fails, the packet (or a retry thereof) | |
30 | passes through in clear or is dropped, depending on local policy. | |
31 | Prearranged tunnels bypass all this, so static VPNs can coexist with | |
32 | opportunistic encryption. | |
33 | ||
34 | xxx here Although significant intelligence about all this is necessary at the | |
35 | initiator end, it's highly desirable for little or no special machinery | |
36 | to be needed at the responder end. In particular, if none were needed, | |
37 | then a security gateway which knows nothing about opportunistic encryption | |
38 | could nevertheless participate in some opportunistic connections. | |
39 | ||
40 | IPSEC gives us the low-level mechanisms, and the key-exchange machinery, | |
41 | but there are some vague spots (to put it mildly) at higher levels. | |
42 | ||
43 | One constraint which deserves comment is that the process of tunnel setup | |
44 | should be quick. Moreover, the decision that no tunnel can be created | |
45 | should also be quick, since that will be a common case, at least in the | |
46 | beginning. People will be reluctant to use opportunistic encryption if it | |
47 | causes gross startup delays on every connection, even connections which see | |
48 | no benefit from it. Win or lose, the process must be rapid. | |
49 | ||
50 | There's nothing much we can do to speed up the key exchange itself. (The | |
51 | one thing which conceivably might be done is to use Aggressive Mode, which | |
52 | involves fewer round trips, but it has limitations and possible security | |
53 | problems, and we're reluctant to touch it.) What we can do, is to make the | |
54 | other parts of the setup process as quick as possible. This desire will | |
55 | come back to haunt us below. :-) | |
56 | ||
57 | A further note is that we must consider the processing at the responder | |
58 | end as well as the initiator end. | |
59 | ||
60 | Several pieces of new machinery are needed to make this work. Here's a | |
61 | brief list, with details considered below. | |
62 | ||
63 | + Outgoing Packet Interception. KLIPS needs to intercept packets which | |
64 | likely would benefit from tunnel setup, and bring them to Pluto's | |
65 | attention. There needs to be enough memory in the process that the same | |
66 | tunnel doesn't get proposed too often (win or lose). | |
67 | ||
68 | + Smart Connection Management. Not only do we need to establish tunnels | |
69 | on request, once a tunnel is set up, it needs to be torn down eventually | |
70 | if it's not in use. It's also highly desirable to detect the fact that it | |
71 | has stopped working, and do something useful. Status changes should be | |
72 | coordinated between the two security gateways unless one has crashed, | |
73 | and even then, they should get back into sync eventually. | |
74 | ||
75 | + Security Gateway Discovery. Given a packet destination, we must decide | |
76 | who to attempt to negotiate a tunnel with. This must be done quickly, win | |
77 | or lose, and reliably even in the presence of diverse network setups. | |
78 | ||
79 | + Authentication Without Prearrangement. We need to be sure we're really | |
80 | talking to the intended security gateway, without being able to prearrange | |
81 | any shared information. He needs the same assurance about us. | |
82 | ||
83 | + More Flexible Policy. In particular, the responding Pluto needs a way | |
84 | to figure out whether the connection it is being asked to make is okay. | |
85 | This isn't as simple as just searching our existing conn database -- we | |
86 | probably have to specify *classes* of legitimate connections. | |
87 | ||
88 | Conveniently, we have a three-letter acronym for each of these. :-) | |
89 | ||
90 | Note on philosophy: we have deliberately avoided providing six different | |
91 | ways to do each step, in favor of specifying one good one. Choices are | |
92 | provided only when they appear to be necessary. (Or when we are not yet | |
93 | quite sure yet how best to do something...) | |
94 | ||
95 | ||
96 | ||
97 | OPI, SCM | |
98 | ||
99 | Smart Connection Management would be quite useful even by itself, | |
100 | requiring manual triggering. (Right now, we do the manual triggering, but | |
101 | not the other parts of SCM.) Outgoing Packet Interception fits together | |
102 | with SCM quite well, and improves its usefulness further. Going through a | |
103 | connection's life cycle from the start... | |
104 | ||
105 | OPI itself is relatively straightforward, aside from the nagging question | |
106 | of whether the intercepted packet is put on hold and then released, or | |
107 | dropped. Putting it on hold is preferable; the alternative is to rely on | |
108 | the application or the transport layer re-trying. The downside of packet | |
109 | hold is extra resources; the downside of packet dropping is that IPSEC | |
110 | knows *when* the packet can finally go out, and the higher layers don't. | |
111 | Either way, life gets a little tricky because a quickly-retrying | |
112 | application may try more than once before we know for sure whether a | |
113 | tunnel can be set up, and something has to detect and filter out the | |
114 | duplications. Some ARP implementations use the approach of keeping one | |
115 | packet for an as-yet-unresolved address, and throwing away any more that | |
116 | appear; that seems a reasonable choice. | |
117 | ||
118 | (Is it worth intercepting *incoming* packets, from the outside world, and | |
119 | attempting tunnel setup based on them? Perhaps... if, and only if, we | |
120 | organize AWP so that non-opportunistic SGs can do it somehow. Otherwise, | |
121 | if the other end has not initiated tunnel setup itself, it will not be | |
122 | prepared to do so at our request.) | |
123 | ||
124 | Once a tunnel is up, packets going into it naturally are not intercepted | |
125 | by OPI. However, we need to do something about the flip side of this too: | |
126 | after deciding that we *cannot* set up a tunnel, either because we don't | |
127 | have enough information or because the other security gateway is | |
128 | uncooperative, we have to remember that for a while, so we don't keep | |
129 | knocking on the same locked door. One plausible way of doing that is to | |
130 | set up a bypass "tunnel" -- the equivalent of our current %passthrough | |
131 | connection -- and have it managed like a real SCM tunnel (finite lifespan | |
132 | etc.). This sounds a bit heavyweight, but in practice, the alternatives | |
133 | all end up doing something very similar when examined closely. Note that | |
134 | we need an extra variant of this, a block rather than a bypass, to cover | |
135 | the case where local policy dictates that packets *not* be passed through; | |
136 | we still have to remember the fact that we can't set up a real tunnel. | |
137 | ||
138 | When to tear tunnels down is a bit problematic, but if we're setting up a | |
139 | potentially unbounded number of them, we have to tear them down *somehow* | |
140 | *sometime*. It seems fairly obvious that we set a tentative lifespan, | |
141 | probably fairly short (say 1min), and when it expires, we look to see if | |
142 | the tunnel is still in use (say, has had traffic in the last half of the | |
143 | lifespan). If so, we assign it a somewhat longer lifespan (say 10min), | |
144 | after which we look again. If not, we close it down. (This lifespan is | |
145 | independent of key lifetime; it is just the time when the tunnel's future | |
146 | is next considered. This should happen reasonably frequently, unlike | |
147 | rekeying, which is costly and shouldn't be too frequent.) Multi-step | |
148 | backoff algorithms probably are not worth the trouble; looking every | |
149 | 10min doesn't seem onerous. | |
150 | ||
151 | For the tunnel-expiry decision, we need to know how long it has been since | |
152 | the last traffic went through. A more detailed history of the traffic | |
153 | does not seem very useful; a simple idle timer (or last-traffic timestamp) | |
154 | is both necessary and sufficient. And KLIPS already has this. | |
155 | ||
156 | As noted, default initial lifespan should be short. However, Pluto should | |
157 | keep a history of recently-closed tunnels, to detect cases where a tunnel | |
158 | is being repeatedly re-established and should be given a longer lifespan. | |
159 | (Not only is tunnel setup costly, but it adds user-visible delay, so | |
160 | keeping a tunnel alive is preferable if we have reason to suspect more | |
161 | traffic soon.) Any tunnel re-established within 10min of dying should have | |
162 | 10min added to its initial lifespan. (Just leaving all tunnels open longer | |
163 | is unappealing -- adaptive lifetimes which are sensitive to the behavior | |
164 | of a particular tunnel are wanted. Tunnels are relatively cheap entities | |
165 | for us, but that is not necessarily true of all implementations, and there | |
166 | may also be administrative problems in sorting through large accumulations | |
167 | of idle tunnels.) | |
168 | ||
169 | It might be desirable to have detailed information about the initial | |
170 | packet when determining lifespans. HTTP connections in particular are | |
171 | notoriously bursty and repetitive. | |
172 | ||
173 | Arguably it would be nice to monitor TCP connection status. A still-open | |
174 | TCP connection is almost a guarantee that more traffic is coming, while | |
175 | the closing of the only TCP connection through a tunnel is a good hint | |
176 | that none is. But the monitoring is complex, and it doesn't seem worth | |
177 | the trouble. | |
178 | ||
179 | IKE connections likewise should be torn down when it appears the need has | |
180 | passed. They should linger longer than the last tunnel they administer, | |
181 | just in case they are needed again; the cost of retaining them is low. An | |
182 | SG with only a modest number of them open might want to simply retain each | |
183 | until rekeying time, with more aggressive management cutting in only when | |
184 | the number gets large. (They should be torn down eventually, if only to | |
185 | minimize the length of a status report, but rekeying is the only expensive | |
186 | event for them.) | |
187 | ||
188 | It's worth remembering that tunnels sometimes go down because the other | |
189 | end crashes, or disconnects, or has a network link break, and we don't get | |
190 | any notice of this in the general case. (Even in the event of a crash and | |
191 | successful reboot, we won't hear about it unless the other end has | |
192 | specific reason to talk IKE to us immediately.) Of course, we have to | |
193 | guard against being too quick to respond to temporary network outages, | |
194 | but it's not quite the same issue for us as for TCP, because we can tear | |
195 | down and then re-establish a tunnel without any user-visible effect except | |
196 | a pause in traffic. And if the other end does go down and come back up, | |
197 | we and it can't communicate *at all* (except via IKE) until we tear down | |
198 | our tunnel. | |
199 | ||
200 | So... we need some kind of heartbeat mechanism. Currently there is none | |
201 | in IKE, but there is discussion of changing that, and this seems like the | |
202 | best approach. Doing a heartbeat at the IP level will not tell us about a | |
203 | crash/reboot event, and sending heartbeat packets through tunnels has | |
204 | various complications (they should stop at the far mouth of the tunnel | |
205 | instead of going on to a subnet; they should not count against idle | |
206 | timers; etc.). Heartbeat exchanges obviously should be done only when | |
207 | there are tunnels established *and* there has been no recent incoming | |
208 | traffic through them. It seems reasonable to do them at lifespan ends, | |
209 | subject to appropriate rate limiting when more than one tunnel goes to the | |
210 | same other SG. When all traffic between the two ends is supposed to go | |
211 | via the tunnel, it might be reasonable to do a heartbeat -- subject to a | |
212 | rate limiter to avoid DOS attacks -- if the kernel sees a non-tunnel | |
213 | non-IKE packet from the other end. | |
214 | ||
215 | If a heartbeat gets no response, try a few (say 3) pings to check IP | |
216 | connectivity; if one comes back, try another heartbeat; if it gets no | |
217 | response, the other end has rebooted, or otherwise been re-initialized, | |
218 | and its tunnels should be torn down. If there's no response to the pings, | |
219 | note the fact and try the sequence again at the next lifespan end; if | |
220 | there's nothing then either, declare the tunnels dead. | |
221 | ||
222 | Finally... except in cases where we've decided that the other end is dead | |
223 | or has rebooted, tunnel teardown should always be coordinated with the | |
224 | other end. This means interpreting and sending Delete notifications, and | |
225 | also Initial-Contacts. Receiving a Delete for the other party's tunnel | |
226 | SAs should lead us to tear down our end too -- SAs (SA bundles, really) | |
227 | need to be considered as paired bidirectional entities, even though the | |
228 | low-level protocols don't think of them that way. | |
229 | ||
230 | ||
231 | ||
232 | SGD, AWP | |
233 | ||
234 | Given a packet destination, how do we decide who to (attempt to) negotiate | |
235 | a tunnel with? And as a related issue, how do the negotiating parties | |
236 | authenticate each other? DNSSEC obviously provides the tools for the | |
237 | latter, but how exactly do we use them? | |
238 | ||
239 | Having intercepted a packet, what we know is basically the IP addresses of | |
240 | source and destination (plus, in principle, some information about the | |
241 | desired communication, like protocol and port). We might be able to map | |
242 | the source address to more information about the source, depending on how | |
243 | well we control our local networks, but we know nothing further about the | |
244 | destination. | |
245 | ||
246 | The obvious first thing to do is a DNS reverse lookup on the destination | |
247 | address; that's about all we can do with available data. Ideally, we'd | |
248 | like to get all necessary information with this one DNS lookup, because | |
249 | DNS lookups are time-consuming -- all the more so if they involve a DNSSEC | |
250 | signature-checking treewalk by the name server -- and we've got to hurry. | |
251 | While it is unusual for a reverse lookup to yield records other than PTR | |
252 | records (or possibly CNAME records, for RFC 2317 classless delegation), | |
253 | there's no reason why it can't. | |
254 | ||
255 | (For purposes like logging, a reverse lookup is usually followed by a | |
256 | forward lookup, to verify that the reverse lookup wasn't lying about the | |
257 | host name. For our purposes, this is not vital, since we use stronger | |
258 | authentication methods anyway.) | |
259 | ||
260 | While we want to get as much data as possible (ideally all of it) from one | |
261 | lookup, it is useful to first consider how the necessary information would | |
262 | be obtained if DNS lookups were instantaneous. Two pieces of information | |
263 | are absolutely vital at this point: the IP address of the other end's | |
264 | security gateway, and the SG's public key*. | |
265 | ||
266 | (* Actually, knowledge of the key can be postponed slightly -- it's not | |
267 | needed until the second exchange of the negotiations, while we can't even | |
268 | start negotiations without knowing the IP address. The SG is not | |
269 | necessarily on the plain-IP route to the destination, especially when | |
270 | multiple SGs are present.) | |
271 | ||
272 | Given instantaneous DNS lookups, we would: | |
273 | ||
274 | + Start with a reverse lookup to turn the address into a name. | |
275 | ||
276 | + Look for something like RFC-2782 SRV records using the name, to find out | |
277 | who provides this particular service. If none comes back, we can abandon | |
278 | the whole process. | |
279 | ||
280 | + Select one SRV record, which gives us the name of a target host (plus | |
281 | possibly one or more addresses, if the name server has supplied address | |
282 | records as Additional Data for the SRV records -- this is recommended | |
283 | behavior but is not required). | |
284 | ||
285 | + Use the target name to look up a suitable KEY record, and also address | |
286 | record(s) if they are still needed. | |
287 | ||
288 | This gives us the desired address(es) and key. However, it requires three | |
289 | lookups, and we don't even find out whether there's any point in trying | |
290 | until after the second. | |
291 | ||
292 | With real DNS lookups, which are far from instantaneous, some optimization | |
293 | is needed. At the very least, typical cases should need fewer lookups. | |
294 | ||
295 | So when we do the reverse lookup on the IP address, instead of asking for | |
296 | PTR, we ask for TXT. If we get none, we abandon opportunistic | |
297 | negotiation, and set up a bypass/block with a relatively long life (say | |
298 | 6hr) because it's not worth trying again soon. (Note, there needs to be a | |
299 | way to manually force an early retry -- say, by just clearing out all | |
300 | memory of a particular address -- to cover cases where a configuration | |
301 | error is discovered and fixed.) | |
302 | ||
303 | xxx need to discuss multi-string TXTs | |
304 | ||
305 | In the results, we look for at least one TXT record with content | |
306 | "X-IPsec-Server(nnn)=a.b.c.d kkk", following RFC 1464 attribute/value | |
307 | notation. (The "X-" indicates that this is tentative and experimental; | |
308 | this design will probably need modification after initial experiments.) | |
309 | Again, if there is no such record, we abandon opportunistic negotiation. | |
310 | ||
311 | "nnn" and the parentheses surrounding it are optional. If present, it | |
312 | specifies a priority (low number high priority), as for MX records, to | |
313 | control the order in which multiple servers are tried. If there are no | |
314 | priorities, or there are ties, pick one randomly. | |
315 | ||
316 | "a.b.c.d" is the dotted-decimal IP address of the SG. (Suitable extensions | |
317 | for IPv6, when the time comes, are straightforward.) | |
318 | ||
319 | "kkk" is either an RSA-MD5 public key in base-64 notation, as in the text | |
320 | form of an RFC 2535 KEY record, or "@hhh". In the latter case, hhh is a | |
321 | DNS name, under which one Host/Authentication/IPSEC/RSA-MD5 KEY record is | |
322 | present, giving the server's authentication key. (The delay of the extra | |
323 | lookup is undesirable, but practical issues of key management may make it | |
324 | advisable not to duplicate the key itself in DNS entries for many | |
325 | clients.) | |
326 | ||
327 | It unfortunately does appear that the authentication key has to be | |
328 | associated with the server, not the client behind it. At the time when | |
329 | the responder has to authenticate our SG, it does not know which of its | |
330 | clients we are interested in (i.e., which key to use), and there is no | |
331 | good way to tell it. (There are some bad ways; this decision may merit | |
332 | re-examination after experimental use.) | |
333 | ||
334 | The responder authenticates our SG by doing a reverse lookup on its IP | |
335 | address to get a Host/Authentication/IPSEC/RSA-MD5 KEY record. He can | |
336 | attempt this in parallel with the early parts of the negotiation (since he | |
337 | knows our SG IP address from the first negotiation packet), at the risk of | |
338 | having to abandon the attempt and do a different lookup if we use | |
339 | something different as our ID (see below). Unfortunately, he doesn't yet | |
340 | know what client we will claim to represent, so he'll need to do another | |
341 | lookup as part of phase 2 negotiation (unless the client *is* our SG), to | |
342 | confirm that the client has a TXT X-IPsec-Server record pointing to our | |
343 | SG. (Checking that the record specifies the same key is not important, | |
344 | since the responder already has a trustworthy key for our SG.) | |
345 | ||
346 | Also unfortunately, opportunistic tunnels can only have degenerate subnets | |
347 | (/32 subnets, containing one host) at their ends. It's superficially | |
348 | attractive to negotiate broader connections... but without prearrangement, | |
349 | you don't know whether you can trust the other end's claim to have a | |
350 | specific subnet behind it. Fixing this would require a way to do a | |
351 | reverse lookup on the *subnet* (you cannot trust information in DNS | |
352 | records for a name or a single address, which may be controlled by people | |
353 | who do not control the whole subnet) with both the address and the mask | |
354 | included in the name. Except in the special case of a subnet masked on a | |
355 | byte boundary (in which case RFC 1035's convention of an incomplete | |
356 | in-addr.arpa name could be used), this would need extensions to the | |
357 | reverse-map name space, which is awkward, especially in the presence of | |
358 | RFC 2317 delegation. (IPv6 delegation is more flexible and it might be | |
359 | easier there.) | |
360 | ||
361 | There is a question of what ID should be used in later steps of | |
362 | negotiation. However, the desire not to put more DNS lookups in the | |
363 | critical path suggests avoiding the extra complication of varied IDs, | |
364 | except in the Road Warrior case (where an extra lookup is inevitable). | |
365 | Also, figuring out what such IDs *mean* gets messy. To keep things simple, | |
366 | except in the RW case, all IDs should be IP addresses identical to those | |
367 | used in the packet headers. | |
368 | ||
369 | For Road Warrior, the RW must be the initiator, since the home-base SG has | |
370 | no idea what address the RW will appear at. Moreover, in general the RW | |
371 | does not control the DNS entries for his address. This inherently denies | |
372 | the home base any authentication of the RW's IP address; the most it can | |
373 | do is to verify an identity he provides, and perhaps decide whether it | |
374 | wishes to talk to someone with that identity, but this does not verify his | |
375 | right to use that IP address -- nothing can, really. | |
376 | ||
377 | (That may sound like it would permit some man-in-the-middle attacks, but | |
378 | the RW can still do full authentication of the home base, so a man in the | |
379 | middle cannot successfully impersonate home base. Furthermore, a man in | |
380 | the middle must impersonate both sides for the DH exchange to work. So | |
381 | either way, the IKE negotiation falls apart.) | |
382 | ||
383 | A Road Warrior provides an FQDN ID, used for a forward lookup to obtain a | |
384 | Host/Authentication/IPSEC/RSA-MD5 KEY record. (Note, an FQDN need not | |
385 | actually correspond to a host -- e.g., the DNS data for it need not | |
386 | include an A record.) This suffices, since the RW is the initiator and | |
387 | the responder knows his address from his first packet. | |
388 | ||
389 | Certain situations where a host has a more-or-less permanent IP address, | |
390 | but does not control its DNS entries, must be treated essentially like | |
391 | Road Warrior. It is unfortunate that DNS's old inverse-query feature | |
392 | cannot be used (nonrecursively) to ask the initiator's local DNS server | |
393 | whether it has a name for the address, because the address will almost | |
394 | always have been obtained from a DNS name lookup, and it might be a lookup | |
395 | of a name whose DNS entries the host *does* control. (Real examples of | |
396 | this exist: the host has a preferred name whose host-controlled entry | |
397 | includes an A record, but a reverse lookup on the address sends you to an | |
398 | ISP-controlled name whose entry has an A record but not much else.) Alas, | |
399 | inverse query is long obsolete and is not widely implemented now. | |
400 | ||
401 | There are some questions in failure cases. If we cannot acquire the info | |
402 | needed to set up a tunnel, this is the no-tunnel-possible case. If we | |
403 | reach an SG but negotiation fails, this too is the no-tunnel-possible | |
404 | case, with a relatively long bypass/block lifespan (say 1hr) since | |
405 | fruitless negotiations are expensive. (In the multiple-SG case, it seems | |
406 | unlikely to be worthwhile to try other SGs just in case one of them might | |
407 | have a configuration permitting successful negotiation.) | |
408 | ||
409 | Finally, there is a sticky problem with timeouts. If the other SG is down | |
410 | or otherwise inaccessible, in the worst case we won't hear about this | |
411 | except by not getting responses. Some other, more pathological or even | |
412 | evil, failure cases can have the same result. The problem is that in the | |
413 | case where a bypass is permitted, we want to decide whether a tunnel is | |
414 | possible quickly. It gets even worse if there are multiple SGs, in which | |
415 | case conceivably we might want to try them all (since some SGs being up | |
416 | when others are down is much more likely than SGs differing in policy). | |
417 | ||
418 | The patience setting needs to be configurable policy, with a reasonable | |
419 | default (to be determined by experiment). If it expires, we simply have | |
420 | to declare the attempt a failure, and set up a bypass/block. (Setting up | |
421 | a tentative bypass/block, and replacing it with a real tunnel if remaining | |
422 | attempts do produce one, looks attractive at first glance... but exposing | |
423 | the first few seconds of a connection is often almost as bad as exposing | |
424 | the whole thing!) Such a bypass/block should have a short lifespan, say | |
425 | 10min, because the SG(s) might be only temporarily unavailable. | |
426 | ||
427 | The flip side of IKE waiting for a timeout is that all other forms of | |
428 | feedback, e.g. "host not reachable", should be *ignored*, because you | |
429 | cannot trust them! This may need kernel changes. | |
430 | ||
431 | Can AWP be done by non-opportunistic SGs? Probably not; existing SG | |
432 | implementations generally aren't prepared to do anything suitable, except | |
433 | perhaps via the messy business of certificates. There is one borderline | |
434 | exception: some implementations rely on LDAP for at least some of their | |
435 | information fetching, and it might be possible to substitute a custom LDAP | |
436 | server which does the right things for them. Feasibility of this depends | |
437 | on details, which we don't know well enough. | |
438 | ||
439 | [This could do with a full example, a complete packet by packet walkthrough | |
440 | including all DNS and IKE traffic.] | |
441 | ||
442 | ||
443 | ||
444 | MFP | |
445 | ||
446 | Our current conn database simply isn't flexible enough to cover all this | |
447 | properly. In particular, the responding Pluto needs a way to figure out | |
448 | whether the connection it is being asked to make is legitimate. | |
449 | ||
450 | This is more subtle than it sounds, given the problem noted earlier, that | |
451 | there's no clear way to authenticate claims to represent a non-degenerate | |
452 | subnet. Our database has to be able to say "a connection to any host in | |
453 | this subnet is okay" or "a connection to any subnet within this subnet is | |
454 | okay", rather than "a connection to exactly this subnet is okay". (There | |
455 | is some analogy to the Road Warrior case here, which may be relevant.) | |
456 | This will require at least a re-interpretation of ipsec.conf. | |
457 | ||
458 | Interim stages of implementation of this will require a bit of thought. | |
459 | Notably, we need some way of dealing with the lack of fully signed DNSSEC | |
460 | records. Without user interaction, probably the best we can do is to | |
461 | remember the results of old fetches, compare them to the results of new | |
462 | fetches, and complain and disbelieve all of it if there's a mismatch. | |
463 | This does mean that somebody who gets fake data into our very first fetch | |
464 | will fool us, at least for a while, but that seems an acceptable tradeoff. | |
465 | ||
466 | ||
467 | ||
468 | Negotiation Issues | |
469 | ||
470 | There are various options which are nominally open to negotiation as part | |
471 | of setup, but which have to be nailed down at least well enough that | |
472 | opportunistic SGs can reliably interoperate. Somewhat arbitrarily and | |
473 | tentatively, opportunistic SGs must support Main Mode, Oakley group 5 for | |
474 | D-H, 3DES encryption and MD5 authentication for both ISAKMP and IPsec SAs, | |
475 | RSA digital-signature authentication with keys between 2048 and 8192 bits, | |
476 | and ESP doing both encryption and authentication. They must do key PFS | |
477 | in Quick Mode, but not identity PFS. | |
478 | ||
479 | ||
480 | ||
481 | What we need from DNS | |
482 | ||
483 | Fortunately, we don't need any new record types or suchlike to make this | |
484 | all work. We do, however, need attention to a couple of areas in DNS | |
485 | implementation. | |
486 | ||
487 | First, size limits. Although the information we directly need from a | |
488 | lookup is not enormous -- the only potentially-big item is the KEY record, | |
489 | and there should be only one of those -- there is still a problem with | |
490 | DNSSEC authentication signatures. With a 2048-bit key and assorted | |
491 | supporting information, we will fill most of a 512-byte DNS UDP packet... | |
492 | and if the data is to have DNSSEC authentication, at least one quite large | |
493 | SIG record will come too. Plus maybe a TSIG signature on the whole | |
494 | response, to authenticate it to our resolver. So: DNSSEC-capable name | |
495 | servers must fix the 512-byte UDP limit. We're told there are provisions | |
496 | for this; implementation of them is mandatory. | |
497 | ||
498 | Second, interface. It is unclear how the resolver interface will let us | |
499 | ask for DNSSEC authentication. We would prefer to ask for "authentication | |
500 | where possible", and get back the data with each item flagged by whether | |
501 | authentication was available (and successful!) or not available. Having | |
502 | to ask separately for authenticated and non-authenticated data would | |
503 | probably be acceptable, *provided* both will be cached on the first | |
504 | request, so the two requests incur only one set of (non-local) network | |
505 | traffic. Either way, we want to see the name server and resolver do this | |
506 | for us; that makes sense in any case, since it's important that | |
507 | verification be done somewhere where it can be cached, the more centrally | |
508 | the better. | |
509 | ||
510 | Finally, a wistful note: the ability to do a limited form of inverse | |
511 | queries (an almost forgotten feature), to ask the local name server which | |
512 | hostname it recently mapped to a particular address, would be quite | |
513 | helpful. Note, this is *NOT* the same as a reverse lookup, and crude | |
514 | fakes like putting a dotted-decimal address in brackets do not suffice. |