]>
Commit | Line | Data |
---|---|---|
997358a6 MW |
1 | <?xml version="1.0"?> |
2 | <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> | |
3 | <?rfc toc="yes"?> | |
4 | <?rfc tocdepth='2' ?> | |
5 | ||
6 | <rfc ipr="full2026" docName="draft-richardson-ipsec-opportunistic-12.txt"> | |
7 | ||
8 | <front> | |
9 | <area>Security</area> | |
10 | <workgroup>Independent submission</workgroup> | |
11 | <title abbrev="opportunistic"> | |
12 | Opportunistic Encryption using The Internet Key Exchange (IKE) | |
13 | </title> | |
14 | ||
15 | <author initials="M." surname="Richardson" fullname="Michael C. Richardson"> | |
16 | <organization abbrev="SSW">Sandelman Software Works</organization> | |
17 | <address> | |
18 | <postal> | |
19 | <street>470 Dawson Avenue</street> | |
20 | <city>Ottawa</city> | |
21 | <region>ON</region> | |
22 | <code>K1Z 5V7</code> | |
23 | <country>CA</country> | |
24 | </postal> | |
25 | <email>mcr@sandelman.ottawa.on.ca</email> | |
26 | <uri>http://www.sandelman.ottawa.on.ca/</uri> | |
27 | </address> | |
28 | </author> | |
29 | ||
30 | <author initials="D.H." surname="Redelmeier" | |
31 | fullname="D. Hugh Redelmeier"> | |
32 | <organization abbrev="Mimosa">Mimosa</organization> | |
33 | <address> | |
34 | <postal> | |
35 | <city>Toronto</city> | |
36 | <region>ON</region> | |
37 | <country>CA</country> | |
38 | </postal> | |
39 | <email>hugh@mimosa.com</email> | |
40 | </address> | |
41 | </author> | |
42 | ||
43 | <date month="June" year="2003"></date> | |
44 | ||
45 | <abstract> | |
46 | <t> | |
47 | This document describes opportunistic encryption (OE) using the Internet Key | |
48 | Exchange (IKE) and IPsec. | |
49 | Each system administrator adds new | |
50 | resource records to his or her Domain Name System (DNS) to support | |
51 | opportunistic encryption. The objective is to allow encryption for secure communication without | |
52 | any pre-arrangement specific to the pair of systems involved. | |
53 | </t> | |
54 | <t> | |
55 | DNS is used to distribute the public keys of each | |
56 | system involved. This is resistant to passive attacks. The use of DNS | |
57 | Security (DNSSEC) secures this system against active attackers as well. | |
58 | </t> | |
59 | <t> | |
60 | As a result, the administrative overhead is reduced | |
61 | from the square of the number of systems to a linear dependence, and it becomes | |
62 | possible to make secure communication the default even | |
63 | when the partner is not known in advance. | |
64 | </t> | |
65 | <t> | |
66 | This document is offered up as an Informational RFC. | |
67 | </t> | |
68 | </abstract> | |
69 | ||
70 | </front> | |
71 | ||
72 | <middle> | |
73 | ||
74 | <section title="Introduction"> | |
75 | ||
76 | <section title="Motivation"> | |
77 | ||
78 | <t> | |
79 | The objective of opportunistic encryption is to allow encryption without | |
80 | any pre-arrangement specific to the pair of systems involved. Each | |
81 | system administrator adds | |
82 | public key information to DNS records to support opportunistic | |
83 | encryption and then enables this feature in the nodes' IPsec stack. | |
84 | Once this is done, any two such nodes can communicate securely. | |
85 | </t> | |
86 | ||
87 | <t> | |
88 | This document describes opportunistic encryption as designed and | |
89 | implemented by the Linux FreeS/WAN project in revisions up and including 2.00. | |
90 | Note that 2.01 and beyond implements RFC3445, in a backward compatible way. | |
91 | For project information, see http://www.freeswan.org. | |
92 | </t> | |
93 | ||
94 | <t> | |
95 | The Internet Architecture Board (IAB) and Internet Engineering | |
96 | Steering Group (IESG) have taken a strong stand that the Internet | |
97 | should use powerful encryption to provide security and | |
98 | privacy <xref target="RFC1984" />. | |
99 | The Linux FreeS/WAN project attempts to provide a practical means to implement this policy. | |
100 | </t> | |
101 | ||
102 | <t> | |
103 | The project uses the IPsec, ISAKMP/IKE, DNS and DNSSEC | |
104 | protocols because they are | |
105 | standardized, widely available and can often be deployed very easily | |
106 | without changing hardware or software or retraining users. | |
107 | </t> | |
108 | ||
109 | <t> | |
110 | The extensions to support opportunistic encryption are simple. No | |
111 | changes to any on-the-wire formats are needed. The only changes are to | |
112 | the policy decision making system. This means that opportunistic | |
113 | encryption can be implemented with very minimal changes to an existing | |
114 | IPsec implementation. | |
115 | </t> | |
116 | ||
117 | <t> | |
118 | Opportunistic encryption creates a "fax effect". The proliferation | |
119 | of the fax machine was possible because it did not require that everyone | |
120 | buy one overnight. Instead, as each person installed one, the value | |
121 | of having one increased - as there were more people that could receive faxes. | |
122 | Once opportunistic encryption is installed it | |
123 | automatically recognizes | |
124 | other boxes using opportunistic encryption, without any further configuration | |
125 | by the network | |
126 | administrator. So, as opportunistic encryption software is installed on more | |
127 | boxes, its value | |
128 | as a tool increases. | |
129 | </t> | |
130 | ||
131 | <t> | |
132 | This document describes the infrastructure to permit deployment of | |
133 | Opportunistic Encryption. | |
134 | </t> | |
135 | ||
136 | <t> | |
137 | The term S/WAN is a trademark of RSA Data Systems, and is used with permission | |
138 | by this project. | |
139 | </t> | |
140 | ||
141 | </section> | |
142 | ||
143 | <section title="Types of network traffic"> | |
144 | <t> | |
145 | To aid in understanding the relationship between security processing and IPsec | |
146 | we divide network traffic into four categories: | |
147 | <list style="hanging"> | |
148 | <t hangText="* Deny:"> networks to which traffic is always forbidden.</t> | |
149 | <t hangText="* Permit:"> networks to which traffic in the clear is permitted.</t> | |
150 | <t hangText="* Opportunistic tunnel:"> networks to which traffic is encrypted if possible, but otherwise is in the clear | |
151 | or fails depending on the default policy in place. | |
152 | </t> | |
153 | <t hangText="* Configured tunnel:"> networks to which traffic | |
154 | must be encrypted, and traffic in the clear is never permitted. | |
155 | A Virtual Private Network (VPN) is a form of configured tunnel. | |
156 | </t> | |
157 | </list> | |
158 | </t> | |
159 | ||
160 | <t> | |
161 | Traditional firewall devices handle the first two categories. | |
162 | No authentication is required. | |
163 | The permit policy is currently the default on the Internet. | |
164 | </t> | |
165 | ||
166 | <t> | |
167 | This document describes the third category - opportunistic tunnel, which is | |
168 | proposed as the new default for the Internet. | |
169 | </t> | |
170 | ||
171 | <t> | |
172 | Category four, encrypt traffic or drop it, requires authentication of the | |
173 | end points. As the number of end points is typically bounded and is typically | |
174 | under a single authority, arranging for distribution of | |
175 | authentication material, while difficult, does not require any new | |
176 | technology. The mechanism described here provides an additional way to | |
177 | distribute the authentication materials, that of a public key method that does not | |
178 | require deployment of an X.509 based infrastructure. | |
179 | </t> | |
180 | <t> | |
181 | Current Virtual Private Networks can often be replaced by an "OE paranoid" | |
182 | policy as described herein. | |
183 | </t> | |
184 | </section> | |
185 | ||
186 | <section title="Peer authentication in opportunistic encryption"> | |
187 | ||
188 | <t> | |
189 | Opportunistic encryption creates tunnels between nodes that | |
190 | are essentially strangers. This is done without any prior bilateral | |
191 | arrangement. | |
192 | There is, therefore, the difficult question of how one knows to whom one is | |
193 | talking. | |
194 | </t> | |
195 | ||
196 | <t> | |
197 | One possible answer is that since no useful | |
198 | authentication can be done, none should be tried. This mode of operation is | |
199 | named "anonymous encryption". An active man-in-the-middle attack can be | |
200 | used to thwart the privacy of this type of communication. | |
201 | Without peer authentication, there is no way to prevent this kind of attack. | |
202 | </t> | |
203 | ||
204 | <t> | |
205 | Although a useful mode, anonymous encryption is not the goal of this | |
206 | project. Simpler methods are available that can achieve anonymous | |
207 | encryption only, but authentication of the peer is a desireable goal. | |
208 | The latter is achieved through key distribution in DNS, leveraging upon | |
209 | the authentication of the DNS in DNSSEC. | |
210 | </t> | |
211 | ||
212 | <t> | |
213 | Peers are, therefore, authenticated with DNSSEC when available. Local policy | |
214 | determines how much trust to extend when DNSSEC is not available. | |
215 | </t> | |
216 | ||
217 | <t> | |
218 | However, an essential premise of building private connections with | |
219 | strangers is that datagrams received through opportunistic tunnels | |
220 | are no more special than datagrams that arrive in the clear. | |
221 | Unlike in a VPN, these datagrams should not be given any special | |
222 | exceptions when it comes to auditing, further authentication or | |
223 | firewalling. | |
224 | </t> | |
225 | ||
226 | <t> | |
227 | When initiating outbound opportunistic encryption, local | |
228 | configuration determines what happens if tunnel setup fails. It may be that | |
229 | the packet goes out in the clear, or it may be dropped. | |
230 | </t> | |
231 | ||
232 | </section> | |
233 | ||
234 | <section title="Use of RFC2119 terms"> | |
235 | <t> | |
236 | The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, | |
237 | SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this | |
238 | document, are to be interpreted as described in <xref target="RFC2119" /> | |
239 | </t> | |
240 | </section> | |
241 | ||
242 | </section> | |
243 | ||
244 | <section title="Overview"> | |
245 | ||
246 | <section title="Reference diagram"> | |
247 | ||
248 | <figure anchor="networkdiagram" title="Reference Network Diagram"> | |
249 | <preamble>The following network diagram is used in the rest of | |
250 | this document as the canonical diagram:</preamble> | |
251 | <artwork> | |
252 | [Q] [R] | |
253 | . . AS2 | |
254 | [A]----+----[SG-A].......+....+.......[SG-B]-------[B] | |
255 | | ...... | |
256 | AS1 | ..PI.. | |
257 | | ...... | |
258 | [D]----+----[SG-D].......+....+.......[C] AS3 | |
259 | ||
260 | ||
261 | </artwork> | |
262 | <postamble></postamble> | |
263 | ||
264 | </figure> | |
265 | ||
266 | <t> | |
267 | In this diagram, there are four end-nodes: A, B, C and D. | |
268 | There are three security gateways, SG-A, SG-B, SG-D. A, D, SG-A and | |
269 | SG-D are part | |
270 | of the same administrative authority, AS1. SG-A and SG-D are on two | |
271 | different exit | |
272 | paths from organization 1. SG-B/B is an independent organization, AS2. | |
273 | Nodes Q and R are nodes on the Internet. PI is the Public | |
274 | Internet ("The Wild"). | |
275 | </t> | |
276 | ||
277 | </section> | |
278 | ||
279 | <section title="Terminology"> | |
280 | ||
281 | <t> | |
282 | The following terminology is used in this document: | |
283 | </t> | |
284 | ||
285 | <list style="hanging"> | |
286 | <t hangText="Security gateway (or simply gateway):"> a system that performs IPsec tunnel | |
287 | mode encapsulation/decapsulation. [SG-x] in the diagram.</t> | |
288 | <t hangText="Alice:"> node [A] in the diagram. When an IP address is needed, this is 192.1.0.65.</t> | |
289 | <t hangText="Bob:"> node [B] in the diagram. When an IP address is needed, this is 192.2.0.66.</t> | |
290 | <t hangText="Carol:"> node [C] in the diagram. When an IP address is needed, this is 192.1.1.67.</t> | |
291 | <t hangText="Dave:"> node [D] in the diagram. When an IP address is needed, this is 192.3.0.68.</t> | |
292 | <t hangText="SG-A:"> Alice's security gateway. Internally it is 192.1.0.1, externally it is 192.1.1.4.</t> | |
293 | <t hangText="SG-B:"> Bob's security gateway. Internally it is 192.2.0.1, externally it is 192.1.1.5.</t> | |
294 | <t hangText="SG-D:"> Dave's security gateway. Also Alice's backup security gateway. Internally it is 192.3.0.1, externally it is 192.1.1.6.</t> | |
295 | <t hangText="."> A period represents an untrusted network of unknown | |
296 | type.</t> | |
297 | <t hangText="Configured tunnel:"> a tunnel that | |
298 | is directly and deliberately hand configured on participating gateways. | |
299 | Configured tunnels are typically given a higher level of | |
300 | trust than opportunistic tunnels.</t> | |
301 | ||
302 | <t hangText="Road warrior tunnel:"> a configured tunnel connecting one | |
303 | node with a fixed IP address and one node with a variable IP address. | |
304 | A road warrior (RW) connection must be initiated by the | |
305 | variable node, since the fixed node cannot know the | |
306 | current address for the road warrior. </t> | |
307 | ||
308 | <t hangText="Anonymous encryption:"> | |
309 | the process of encrypting a session without any knowledge of who the | |
310 | other parties are. No authentication of identities is done.</t> | |
311 | ||
312 | <t hangText="Opportunistic encryption:"> | |
313 | the process of encrypting a session with authenticated knowledge of | |
314 | who the other party is.</t> | |
315 | ||
316 | <t hangText="Lifetime:"> | |
317 | the period in seconds (bytes or datagrams) for which a security | |
318 | association will remain alive before needing to be re-keyed.</t> | |
319 | ||
320 | <t hangText="Lifespan:"> | |
321 | the effective time for which a security association remains useful. A | |
322 | security association with a lifespan shorter than its lifetime would | |
323 | be removed when no longer needed. A security association with a | |
324 | lifespan longer than its lifetime would need to be re-keyed one or | |
325 | more times.</t> | |
326 | ||
327 | <t hangText="Phase 1 SA:"> an ISAKMP/IKE security association sometimes | |
328 | referred to as a keying channel.</t> | |
329 | ||
330 | <t hangText="Phase 2 SA:"> an IPsec security association.</t> | |
331 | ||
332 | <t hangText="Tunnel:"> another term for a set of phase 2 SA (one in each direction).</t> | |
333 | ||
334 | <t hangText="NAT:"> Network Address Translation | |
335 | (see <xref target="RFC2663" />).</t> | |
336 | ||
337 | <t hangText="NAPT:"> Network Address and Port Translation | |
338 | (see <xref target="RFC2663" />).</t> | |
339 | ||
340 | <t hangText="AS:"> an autonomous system </t> | |
341 | ||
342 | <t hangText="FQDN:"> Fully-Qualified Domain Name </t> | |
343 | ||
344 | <t hangText="Default-free zone:"> | |
345 | a set of routers that maintain a complete set of routes to | |
346 | all currently reachable destinations. Having such a list, these routers | |
347 | never make use of a default route. A datagram with a destination address | |
348 | not matching any route will be dropped by such a router. | |
349 | </t> | |
350 | ||
351 | </list> | |
352 | </section> | |
353 | ||
354 | <section title="Model of operation"> | |
355 | ||
356 | <t> | |
357 | The opportunistic encryption security gateway (OE gateway) is a regular | |
358 | gateway node as described in <xref target="RFC0791" /> section 2.4 and | |
359 | <xref target="RFC1009" /> with the additional capabilities described here and | |
360 | in <xref target="RFC2401" />. | |
361 | The algorithm described here provides a way to determine, for each datagram, | |
362 | whether or not to encrypt and tunnel the datagram. Two important things | |
363 | that must be determined are whether or not to encrypt and tunnel and, if | |
364 | so, the destination address or name of the tunnel end point which should be used. | |
365 | </t> | |
366 | ||
367 | <section title="Tunnel authorization"> | |
368 | <t> | |
369 | The OE gateway determines whether or not to create a tunnel based on | |
370 | the destination address of each packet. Upon receiving a packet with a destination | |
371 | address not recently seen, the OE gateway performs a lookup in DNS for an | |
372 | authorization resource record (see <xref target="TXT"/>). The record is located using | |
373 | the IP address to perform a search in the in-addr.arpa (IPv4) or ip6.arpa | |
374 | (IPv6) maps. If an authorization record is found, the OE gateway | |
375 | interprets this as a request for a tunnel to be formed. | |
376 | </t> | |
377 | </section> | |
378 | ||
379 | <section title="Tunnel end-point discovery"> | |
380 | ||
381 | <t> | |
382 | The authorization resource record also provides the address or name of the tunnel | |
383 | end point which should be used. | |
384 | </t> | |
385 | <t> | |
386 | The record may also provide the public RSA key of the tunnel end point | |
387 | itself. This is provided for efficiency only. If the public RSA key is not | |
388 | present, the OE gateway performs a second lookup to find a KEY | |
389 | resource record for the end point address or name. | |
390 | </t> | |
391 | <t> | |
392 | Origin and integrity protection of the resource records is provided by | |
393 | DNSSEC (<xref target="RFC2535"/>). <xref target="nodnssec"/> | |
394 | documents an optional restriction on the tunnel end point if DNSSEC signatures | |
395 | are not available for the relevant records. | |
396 | </t> | |
397 | ||
398 | </section> | |
399 | ||
400 | <section title="Caching of authorization results"> | |
401 | <t> | |
402 | The OE gateway maintains a cache, in the forwarding plane, of | |
403 | source/destination pairs for which opportunistic encryption has been | |
404 | attempted. This cache maintains a record of whether or not OE was | |
405 | successful so that subsequent datagrams can be forwarded properly | |
406 | without additional delay. | |
407 | </t> | |
408 | ||
409 | <t> | |
410 | Successful negotiation of OE instantiates a new security association. | |
411 | Failure to negotiate OE results in creation of a | |
412 | forwarding policy entry either to drop or transmit in the clear future | |
413 | datagrams. This negative cache is necessary to avoid the possibly lengthy process of repeatedly looking | |
414 | up the same information. | |
415 | </t> | |
416 | ||
417 | <t> | |
418 | The cache is timed out periodically, as described in <xref target="teardown" />. | |
419 | This removes entries that are no longer | |
420 | being used and permits the discovery of changes in authorization policy. | |
421 | </t> | |
422 | </section> | |
423 | ||
424 | </section> <!-- "Model of operation" --> | |
425 | ||
426 | </section> <!-- "Overview" --> | |
427 | ||
428 | <section title="Protocol Specification"> | |
429 | ||
430 | <t> | |
431 | The OE gateway is modeled to have a forwarding plane and a control | |
432 | plane. A control channel, such as PF_KEY, connects the two planes. | |
433 | (See <xref target="RFC2367" />.) | |
434 | The forwarding plane performs per datagram operations. The control plane | |
435 | contains a keying daemon, such as ISAKMP/IKE, and performs all | |
436 | authorization, peer authentication and key derivation functions. | |
437 | </t> | |
438 | ||
439 | <section title="Forwarding plane state machine"> | |
440 | ||
441 | <t> | |
442 | Let the OE gateway maintain a collection of objects -- a superset of the | |
443 | security policy database (SPD) specified in <xref target="RFC2401" />. For | |
444 | each combination of source and destination address, an SPD | |
445 | object exists in one of five following states. | |
446 | Prior to forwarding each datagram, the responder uses the source and | |
447 | destination addresses to pick an entry from the SPD. | |
448 | The SPD then determines if and how the packet is forwarded. | |
449 | </t> | |
450 | ||
451 | <!-- from file forwardingstate.txt --> | |
452 | <artwork><![CDATA[ | |
453 | .--------------. | |
454 | | non-existant | | |
455 | | policy | | |
456 | `--------------' | |
457 | | | |
458 | | PF_ACQUIRE | |
459 | | | |
460 | |<---------. | |
461 | V | new packet | |
462 | .--------------. | (maybe resend PF_ACQUIRE) | |
463 | | hold policy |--' | |
464 | | |--. | |
465 | `--------------' \ pass | |
466 | | | \ msg .---------. | |
467 | | | \ V | forward | |
468 | | | .-------------. | packet | |
469 | create | | | pass policy |--' | |
470 | IPsec | | `-------------' | |
471 | SA | | | |
472 | | \ | |
473 | | \ | |
474 | V \ deny | |
475 | .---------. \ msg | |
476 | | encrypt | \ | |
477 | | policy | \ ,---------. | |
478 | `---------' \ | | discard | |
479 | \ V | packet | |
480 | .-------------. | | |
481 | | deny policy |--' | |
482 | '-------------' | |
483 | ]]></artwork> | |
484 | ||
485 | ||
486 | <section title="Non-existent policy"> | |
487 | <t> | |
488 | If the gateway does not find an entry, then this policy applies. | |
489 | The gateway creates an entry with an initial state of "hold policy" and requests | |
490 | keying material from the keying daemon. The gateway does not forward the datagram, | |
491 | rather it SHOULD attach the datagram to the SPD entry as the "first" datagram and retain it | |
492 | for eventual transmission in a new state. | |
493 | ||
494 | </t> | |
495 | </section> | |
496 | ||
497 | <section title="Hold policy"> | |
498 | <t> | |
499 | The gateway requests keying material. If the interface to the keying | |
500 | system is lossy (PF_KEY, for instance, can be), the implementation | |
501 | SHOULD include a mechanism to retransmit the | |
502 | keying request at a rate limited to less than 1 request per second. | |
503 | The gateway does not forward the datagram. The gateway SHOULD attach the | |
504 | datagram to the SPD entry as the "last" datagram where it is retained | |
505 | for eventual transmission. | |
506 | If there is a datagram already so stored, then that already stored datagram is discarded. | |
507 | </t> | |
508 | <t> | |
509 | The rational behind saving the the "first" and "last" datagrams are as follows: | |
510 | The "first" datagram is probably a TCP SYN packet. Once there is keying | |
511 | established, the gateway will release this datagram, avoiding the need to | |
512 | for the end-point to retransmit the datagram. In the case where the connection | |
513 | was not a TCP connection, buyt was instead a streaming protocol or a DNS request, | |
514 | the "last" datagram that was retained is likely the most recent data. The difference | |
515 | between "first" and "last" may also help the end-points determine | |
516 | which data awas dropped while negotiation took place. | |
517 | </t> | |
518 | </section> | |
519 | ||
520 | <section title="Pass-through policy"> | |
521 | <t> | |
522 | The gateway forwards the datagram using the normal forwarding table. | |
523 | The gateway enters this state only by command from the keying daemon, | |
524 | and upon entering this state, also forwards the "first" and "last" datagrams. | |
525 | </t> | |
526 | </section> | |
527 | ||
528 | <section title="Deny policy"> | |
529 | <t> | |
530 | The gateway discards the datagram. The gateway enters this state only by | |
531 | command | |
532 | from the keying daemon, and upon entering this state, discards the "first" | |
533 | and "last" datagrams. | |
534 | An implementation MAY provide the administator with a control to determine | |
535 | if further datagrams cause ICMP messages | |
536 | to be generated (i.e. ICMP Destination Unreachable, Communication | |
537 | Administratively Prohibited. type=3, code=13). | |
538 | </t> | |
539 | </section> | |
540 | ||
541 | <section title="Encrypt policy"> | |
542 | <t> | |
543 | The gateway encrypts the datagram using the indicated security association database | |
544 | (SAD) entry. The gateway enters this state only by command from the keying daemon, and upon entering | |
545 | this state, releases and forwards the "first" and "last" datagrams using the | |
546 | new encrypt policy. | |
547 | </t> | |
548 | <t> | |
549 | If the associated SAD entry expires because of byte, packet or time limits, then | |
550 | the entry returns to the Hold policy, and an expire message is sent to the keying daemon. | |
551 | </t> | |
552 | </section> | |
553 | ||
554 | <t> | |
555 | All states may be created directly by the keying daemon while acting as a | |
556 | gateway. | |
557 | </t> | |
558 | ||
559 | </section> <!-- "Datagram state machine" --> | |
560 | ||
561 | ||
562 | <section anchor="initclasses" title="Keying Daemon -- initiator"> | |
563 | <t> | |
564 | Let the keying daemon maintain a collection of objects. Let them be | |
565 | called "connections" or "conn"s. There are two categories of | |
566 | connection objects: classes and instances. A class represents an | |
567 | abstract policy - what could be. An instance represents an actual connection - | |
568 | what is implemented at the time. | |
569 | </t> | |
570 | ||
571 | <t> | |
572 | Let there be two further subtypes of connections: keying channels (Phase | |
573 | 1 SAs) and data channels (Phase 2 SAs). Each data channel object may have | |
574 | a corresponding SPD and SAD entry maintained by the datagram state machine. | |
575 | </t> | |
576 | ||
577 | <t> | |
578 | For the purposes of opportunistic encryption, there MUST, at least, be | |
579 | connection classes known as "deny", "always-clear-text", "OE-permissive", and | |
580 | "OE-paranoid". | |
581 | The latter two connection classes define a set of source and/or destination | |
582 | addresses for which opportunistic encryption will be attempted. | |
583 | The administrator MAY set policy options in a number of additional places. | |
584 | An implementation MAY create additional connection classes to further refine | |
585 | these policies. | |
586 | </t> | |
587 | ||
588 | <t> | |
589 | The simplest system may need only the "OE-permissive" connection, and would | |
590 | list its own (single) IP address as the source address of this policy and | |
591 | the wild-card address 0.0.0.0/0 as the destination IPv4 address. That is, the | |
592 | simplest policy is to try opportunistic encryption with all destinations. | |
593 | </t> | |
594 | ||
595 | <t> | |
596 | The distinction between permissive and paranoid OE use will become clear | |
597 | in the state transition differences. In general a permissive OE will, on | |
598 | failure, install a pass-through policy, while a paranoid OE will, on failure, | |
599 | install a drop policy. | |
600 | </t> | |
601 | ||
602 | <t> | |
603 | In this description of the keying machine's state transitions, the states | |
604 | associated with the keying system itself are omitted because they are best documented in the keying system | |
605 | (<xref target="RFC2407" />, | |
606 | <xref target="RFC2408" /> and <xref target="RFC2409" /> for ISAKMP/IKE), | |
607 | and the details are keying system specific. Opportunistic encryption is not | |
608 | dependent upon any specific keying protocol, but this document does provide | |
609 | requirements for those using ISAKMP/IKE to assure that implementations inter-operate. | |
610 | </t> | |
611 | <t> | |
612 | The state transitions that may be involved in communicating with the | |
613 | forwarding plane are omitted. PF_KEY and similar protocols have their own | |
614 | set of states required for message sends and completion notifications. | |
615 | </t> | |
616 | <t> | |
617 | Finally, the retransmits and recursive lookups that are normal for DNS are | |
618 | not included in this description of the state machine. | |
619 | </t> | |
620 | ||
621 | <!-- from file initiatorstate.txt --> | |
622 | <artwork><![CDATA[ | |
623 | ||
624 | | | |
625 | | PF_ACQUIRE | |
626 | | | |
627 | V | |
628 | .---------------. | |
629 | | non-existant | | |
630 | | connection | | |
631 | `---------------' | |
632 | | | | | |
633 | send , | \ | |
634 | expired pass / | \ send | |
635 | conn. msg / | \ deny | |
636 | ^ / | \ msg | |
637 | | V | do \ | |
638 | .---------------. | DNS \ .---------------. | |
639 | | clear-text | | lookup `->| deny |---> expired | |
640 | | connection | | for | connection | connection | |
641 | `---------------' | destination `---------------' | |
642 | ^ ^ | ^ | |
643 | | | no record | | | |
644 | | | OE-permissive V | no record | |
645 | | | .---------------. | OE-paranoid | |
646 | | `------------| potential OE |---------' | |
647 | | | connection | ^ | |
648 | | `---------------' | | |
649 | | | | | |
650 | | | got TXT record | DNSSEC failure | |
651 | | | reply | | |
652 | | V | wrong | |
653 | | .---------------. | failure | |
654 | | | authenticate |---------' | |
655 | | | & parse TXT RR| ^ | |
656 | | repeated `---------------' | | |
657 | | ICMP | | | |
658 | | failures | initiate IKE to | | |
659 | | (short-timeout) | responder | | |
660 | | V | | |
661 | | phase-2 .---------------. | failure | |
662 | | failure | pending |---------' | |
663 | | (normal | OE | ^ | |
664 | | timeout) | |invalid | phase-2 failure (short-timeout) | |
665 | | | |<--.SPI | ICMP failures (normal timeout) | |
666 | | | | | | | |
667 | | | +=======+ |---' | | |
668 | | | | IKE | | ^ | | |
669 | `--------------| | states|---------------' | |
670 | | +=======+ | | | |
671 | `---------------' | | |
672 | | IPsec SA | invalid SPI | |
673 | | established | | |
674 | V | rekey time | |
675 | .--------------. | | |
676 | | keyed |<---|-------------------------------. | |
677 | | connection |----' | | |
678 | `--------------' | | |
679 | | timer | | |
680 | | | | |
681 | V | | |
682 | .--------------. connection still active | | |
683 | clear-text----->| expired |------------------------------------' | |
684 | deny----->| connection | | |
685 | `--------------' | |
686 | | dead connected - deleted | |
687 | V | |
688 | ]]></artwork> | |
689 | ||
690 | ||
691 | <section title="Nonexistent connection"> | |
692 | <t> | |
693 | There is no connection instance for a given source/destination address pair. | |
694 | Upon receipt of a request for keying material for this | |
695 | source/destination pair, the initiator searches through the connection classes to | |
696 | determine the most appropriate policy. Upon determining an appropriate | |
697 | connection class, an instance object is created of that type. | |
698 | Both of the OE types result in a potential OE connection. | |
699 | </t> | |
700 | <t>Failure to find an appropriate connection class results in an | |
701 | administrator defined default. | |
702 | </t> | |
703 | <t> | |
704 | In each case, when the initiator finds an appropriate class for the new flow, | |
705 | an instance connection is made of the class which matched. | |
706 | </t> | |
707 | </section> | |
708 | ||
709 | <section title="Clear-text connection"> | |
710 | <t> | |
711 | The non-existent connection makes a transition to this state when an | |
712 | always-clear-text class is instantiated, or when an OE-permissive | |
713 | connection fails. During the transition, the initiator creates a pass-through | |
714 | policy object in the forwarding plane for the appropriate flow. | |
715 | </t> | |
716 | <t> | |
717 | Timing out is the only way to leave this state | |
718 | (see <xref target="expiring" />). | |
719 | </t> | |
720 | </section> | |
721 | ||
722 | <section title="Deny connection"> | |
723 | <t> | |
724 | The empty connection makes a transition to this state when a | |
725 | deny class is instantiated, or when an OE-paranoid connection fails. | |
726 | During the transition, the initiator creates a deny policy object in the forwarding plane | |
727 | for the appropriate flow. | |
728 | </t> | |
729 | <t> | |
730 | Timing out is the only way to leave this state | |
731 | (see <xref target="expiring" />). | |
732 | </t> | |
733 | </section> | |
734 | ||
735 | <section title="Potential OE connection"> | |
736 | <t> | |
737 | The empty connection makes a transition to this state when one of either OE class is instantiated. | |
738 | During the transition to this state, the initiator creates a hold policy object in the | |
739 | forwarding plane for the appropriate flow. | |
740 | </t> | |
741 | <t> | |
742 | In addition, when making a transition into this state, DNS lookup is done in | |
743 | the reverse-map for a TXT delegation resource record (see <xref target="TXT" />). | |
744 | The lookup key is the destination address of the flow. | |
745 | </t> | |
746 | <t> | |
747 | There are three ways to exit this state: | |
748 | <list style="numbers"> | |
749 | <t>DNS lookup finds a TXT delegation resource record.</t> | |
750 | <t>DNS lookup does not find a TXT delegation resource record.</t> | |
751 | <t>DNS lookup times out.</t> | |
752 | </list> | |
753 | </t> | |
754 | ||
755 | <t> | |
756 | Based upon the results of the DNS lookup, the potential OE connection makes a | |
757 | transition to the pending OE connection state. The conditions for a | |
758 | successful DNS look are: | |
759 | <list style="numbers"> | |
760 | <t>DNS finds an appropriate resource record</t> | |
761 | <t>It is properly formatted according to <xref target="TXT" /></t> | |
762 | <t> if DNSSEC is enabled, then the signature has been vouched for.</t> | |
763 | </list> | |
764 | ||
765 | Note that if the initiator does not find the public key | |
766 | present in the TXT delegation record, then the public key must | |
767 | be looked up as a sub-state. Only successful completion of all the | |
768 | DNS lookups is considered a success. | |
769 | </t> | |
770 | <t> | |
771 | If DNS lookup does not find a resource record or DNS times out, then the | |
772 | initiator considers the receiver not OE capable. If this is an OE-paranoid instance, | |
773 | then the potential OE connection makes a transition to the deny connection state. | |
774 | If this is an OE-permissive instance, then the potential OE connection makes a transition to the | |
775 | clear-text connection state. | |
776 | </t> | |
777 | <t> | |
778 | If the initiator finds a resource record but it is not properly formatted, or | |
779 | if DNSSEC is | |
780 | enabled and reports a failure to authenticate, then the potential OE | |
781 | connection makes a | |
782 | transition to the deny connection state. This action SHOULD be logged. If the | |
783 | administrator wishes to override this transition between states, then an | |
784 | always-clear class can be installed for this flow. An implementation MAY make | |
785 | this situation a new class. | |
786 | </t> | |
787 | ||
788 | <section anchor="nodnssec" title="Restriction on unauthenticated TXT delegation records"> | |
789 | <t> | |
790 | An implementation SHOULD also provide an additional administrative control | |
791 | on delegation records and DNSSEC. This control would apply to delegation | |
792 | records (the TXT records in the reverse-map) that are not protected by | |
793 | DNSSEC. | |
794 | Records of this type are only permitted to delegate to their own address as | |
795 | a gateway. When this option is enabled, an active attack on DNS will be | |
796 | unable to redirect packets to other than the original destination. | |
797 | <!-- This was asked for by Bill Sommerfeld --> | |
798 | </t> | |
799 | </section> | |
800 | </section> | |
801 | ||
802 | <section title="Pending OE connection"> | |
803 | <t> | |
804 | The potential OE connection makes a transition to this state when | |
805 | the initiator determines that all the information required from the DNS lookup is present. | |
806 | Upon entering this state, the initiator attempts to initiate keying to the gateway | |
807 | provided. | |
808 | </t> | |
809 | <t> | |
810 | Exit from this state occurs either with a successfully created IPsec SA, or | |
811 | with a failure of some kind. Successful SA creation results in a transition | |
812 | to the key connection state. | |
813 | </t> | |
814 | <t> | |
815 | Three failures have caused significant problems. They are clearly not the | |
816 | only possible failures from keying. | |
817 | </t> | |
818 | <t> | |
819 | Note that if there are multiple gateways available in the TXT delegation | |
820 | records, then a failure can only be declared after all have been | |
821 | tried. Further, creation of a phase 1 SA does not constitute success. A set | |
822 | of phase 2 SAs (a tunnel) is considered success. | |
823 | </t> | |
824 | <t> | |
825 | The first failure occurs when an ICMP port unreachable is consistently received | |
826 | without any other communication, or when there is silence from the remote | |
827 | end. This usually means that either the gateway is not alive, or the | |
828 | keying daemon is not functional. For an OE-permissive connection, the initiator makes a transition | |
829 | to the clear-text connection but with a low lifespan. For an OE-pessimistic connection, | |
830 | the initiator makes a transition to the deny connection again with a low lifespan. The | |
831 | lifespan in both | |
832 | cases is kept low because the remote gateway may | |
833 | be in the process of rebooting or be otherwise temporarily unavailable. | |
834 | </t> | |
835 | <t> | |
836 | The length of time to wait for the remote keying daemon to wake up is | |
837 | a matter of some debate. If there is a routing failure, 5 minutes is usually long | |
838 | enough for the network to | |
839 | re-converge. Many systems can reboot in that amount of | |
840 | time as well. However, 5 minutes is far too long for most users to wait to | |
841 | hear that they can not connect using OE. Implementations SHOULD make this a | |
842 | tunable parameter. | |
843 | </t> | |
844 | <t> | |
845 | The second failure occurs after a phase 1 SA has been created, but there is | |
846 | either no response to the phase 2 proposal, or the initiator receives a | |
847 | negative notify (the notify must be | |
848 | authenticated). The remote gateway is not prepared to do OE at this time. | |
849 | As before, the initiator makes a transition to the clear-text or the deny | |
850 | connection based upon connection class, but this | |
851 | time with a normal lifespan. | |
852 | </t> | |
853 | <t> | |
854 | The third failure occurs when there is signature failure while authenticating | |
855 | the remote gateway. This can occur when there has been a | |
856 | key roll-over, but DNS has not caught up. In this case again, the initiator makes a | |
857 | transition to the clear-text or the deny connection based | |
858 | upon the connection class. However, the lifespan depends upon the remaining | |
859 | time to live in the DNS. (Note that DNSSEC signed resource records have a different | |
860 | expiry time than non-signed records.) | |
861 | <!-- dig @gateway would also work here --> | |
862 | </t> | |
863 | ||
864 | </section> | |
865 | ||
866 | <section anchor="keyed" title="Keyed connection"> | |
867 | <t> | |
868 | The pending OE connection makes a transition to this state when | |
869 | session keying material (the phase 2 SAs) is derived. The initiator creates an encrypt | |
870 | policy in the forwarding plane for this flow. | |
871 | </t> | |
872 | <t> | |
873 | There are three ways to exit this state. The first is by receipt of an | |
874 | authenticated delete message (via the keying channel) from the peer. This is | |
875 | normal teardown and results in a transition to the expired connection state. | |
876 | </t> | |
877 | <t> | |
878 | The second exit is by expiry of the forwarding plane keying material. This | |
879 | starts a re-key operation with a transition back to pending OE | |
880 | connection. In general, the soft expiry occurs with sufficient time left | |
881 | to continue to use the keys. A re-key can fail, which may | |
882 | result in the connection failing to clear-text or deny as | |
883 | appropriate. In the event of a failure, the forwarding plane | |
884 | policy does not change until the phase 2 SA (IPsec SA) reaches its | |
885 | hard expiry. | |
886 | </t> | |
887 | <t> | |
888 | The third exit is in response to a negotiation from a remote | |
889 | gateway. If the forwarding plane signals the control plane that it has received an | |
890 | unknown SPI from the remote gateway, or an ICMP is received from the remote gateway | |
891 | indicating an unknown SPI, the initiator should consider that | |
892 | the remote gateway has rebooted or restarted. Since these | |
893 | indications are easily forged, the implementation must | |
894 | exercise care. The initiator should make a cautious | |
895 | (rate-limited) attempt to re-key the connection. | |
896 | </t> | |
897 | </section> | |
898 | ||
899 | <section anchor="expiring" title="Expiring connection"> | |
900 | <t> | |
901 | The initiator will periodically place each of the deny, clear-text, and keyed | |
902 | connections into this | |
903 | sub-state. See <xref target="teardown" /> for more details of how often this | |
904 | occurs. | |
905 | The initiator queries the forwarding plane for last use time of the | |
906 | appropriate | |
907 | policy. If the last use time is relatively recent, then the connection | |
908 | returns to the | |
909 | previous deny, clear-text or keyed connection state. If not, then the | |
910 | connection enters | |
911 | the expired connection state. | |
912 | </t> | |
913 | <t> | |
914 | The DNS query and answer that lead to the expiring connection state are also | |
915 | examined. The DNS query may become stale. (A negative, i.e. no such record, answer | |
916 | is valid for the period of time given by the MINIMUM field in an attached SOA | |
917 | record. See <xref target="RFC1034" /> section 4.3.4.) | |
918 | If the DNS query is stale, then a new query is made. If the results change, then the connection | |
919 | makes a transition to a new state as described in potential OE connection state. | |
920 | </t> | |
921 | <t> | |
922 | Note that when considering how stale a connection is, both outgoing SPD and | |
923 | incoming SAD must be queried as some flows may be unidirectional for some time. | |
924 | </t> | |
925 | <t> | |
926 | Also note that the policy at the forwarding plane is not updated unless there | |
927 | is a conclusion that there should be a change. | |
928 | </t> | |
929 | ||
930 | </section> | |
931 | <section title="Expired connection"> | |
932 | <t> | |
933 | Entry to this state occurs when no datagrams have been forwarded recently via the | |
934 | appropriate SPD and SAD objects. The objects in the forwarding plane are | |
935 | removed (logging any final byte and packet counts if appropriate) and the | |
936 | connection instance in the keying plane is deleted. | |
937 | </t> | |
938 | <t> | |
939 | The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs as described in | |
940 | <xref target="teardown" />. | |
941 | </t> | |
942 | <t> | |
943 | Whether or not to delete the phase 1 SAs | |
944 | at this time is left as a local implementation issue. Implementations | |
945 | that do delete the phase 1 SAs MUST send authenticated delete messages to | |
946 | indicate that they are doing so. There is an advantage to keeping | |
947 | the phase 1 SAs until they expire - they may prove useful again in the | |
948 | near future. | |
949 | </t> | |
950 | </section> | |
951 | ||
952 | </section> <!-- "Keying state machine - initiator" --> | |
953 | ||
954 | <section title="Keying Daemon - responder"> | |
955 | <t> | |
956 | The responder has a set of objects identical to those of the initiator. | |
957 | </t> | |
958 | <t> | |
959 | The responder receives an invitation to create a keying channel from an initiator. | |
960 | </t> | |
961 | ||
962 | <!-- from file responderstate.txt --> | |
963 | <artwork><![CDATA[ | |
964 | | | |
965 | | IKE main mode | |
966 | | phase 1 | |
967 | V | |
968 | .-----------------. | |
969 | | unauthenticated | | |
970 | | OE peer | | |
971 | `-----------------' | |
972 | | | |
973 | | lookup KEY RR in in-addr.arpa | |
974 | | (if ID_IPV4_ADDR) | |
975 | | lookup KEY RR in forward | |
976 | | (if ID_FQDN) | |
977 | V | |
978 | .-----------------. RR not found | |
979 | | received DNS |---------------> log failure | |
980 | | reply | | |
981 | `----+--------+---' | |
982 | phase 2 | \ misformatted | |
983 | proposal | `------------------> log failure | |
984 | V | |
985 | .----------------. | |
986 | | authenticated | identical initiator | |
987 | | OE peer |--------------------> initiator | |
988 | `----------------' connection found state machine | |
989 | | | |
990 | | look for TXT record for initiator | |
991 | | | |
992 | V | |
993 | .---------------. | |
994 | | authorized |---------------------> log failure | |
995 | | OE peer | | |
996 | `---------------' | |
997 | | | |
998 | | | |
999 | V | |
1000 | potential OE | |
1001 | connection in | |
1002 | initiator state | |
1003 | machine | |
1004 | ||
1005 | ||
1006 | $Id: draft-richardson-ipsec-opportunistic.xml,v 1.1 2004/03/15 20:35:24 as Exp $ | |
1007 | ]]></artwork> | |
1008 | ||
1009 | ||
1010 | <section title="Unauthenticated OE peer"> | |
1011 | <t> | |
1012 | Upon entering this state, the responder starts a DNS lookup for a KEY record for the | |
1013 | initiator. | |
1014 | The responder looks in the reverse-map for a KEY record for the initiator if the | |
1015 | initiator has offered an ID_IPV4_ADDR, and in the forward map if the | |
1016 | initiator has offered an ID_FQDN type. (See <xref target="RFC2407" /> section | |
1017 | 4.6.2.1.) | |
1018 | </t> | |
1019 | <t> | |
1020 | The responder exits this state upon successful receipt of a KEY from DNS, and use of the key | |
1021 | to verify the signature of the initiator. | |
1022 | </t> | |
1023 | ||
1024 | <!-- | |
1025 | <t> | |
1026 | The public key that is retrieved should be stored in stable storage for an | |
1027 | administratively defined period of time, (typically several months if | |
1028 | possible). If a key has previously been stored on disk, then the returned key | |
1029 | should be compared to what has been received, and the key considered valid | |
1030 | only if they match. | |
1031 | </t> | |
1032 | --> | |
1033 | ||
1034 | <t> | |
1035 | Successful authentication of the peer results in a transition to the | |
1036 | authenticated OE Peer state. | |
1037 | </t> | |
1038 | <t> | |
1039 | Note that the unauthenticated OE peer state generally occurs in the middle of the key negotiation | |
1040 | protocol. It is really a form of pseudo-state. | |
1041 | </t> | |
1042 | </section> | |
1043 | ||
1044 | <section title="Authenticated OE Peer"> | |
1045 | <t> | |
1046 | The peer will eventually propose one or more phase 2 SAs. The responder uses the source and | |
1047 | destination address in the proposal to | |
1048 | finish instantiating the connection state | |
1049 | using the connection class table. | |
1050 | The responder MUST search for an identical connection object at this point. | |
1051 | </t> | |
1052 | <t> | |
1053 | If an identical connection is found, then the responder deletes the old instance, | |
1054 | and the new object makes a transition to the pending OE connection state. This means | |
1055 | that new ISAKMP connections with a given peer will always use the latest | |
1056 | instance, which is the correct one if the peer has rebooted in the interim. | |
1057 | </t> | |
1058 | <t> | |
1059 | If an identical connection is not found, then the responder makes the transition according to the | |
1060 | rules given for the initiator. | |
1061 | </t> | |
1062 | <t> | |
1063 | Note that if the initiator is in OE-paranoid mode and the responder is in | |
1064 | either always-clear-text or deny, then no communication is possible according | |
1065 | to policy. An implementation is permitted to create new types of policies | |
1066 | such as "accept OE but do not initiate it". This is a local matter. | |
1067 | </t> | |
1068 | </section> | |
1069 | ||
1070 | </section> <!-- "Keying state machine - responder" --> | |
1071 | ||
1072 | <section anchor="teardown" title="Renewal and teardown"> | |
1073 | <section title="Aging"> | |
1074 | <t> | |
1075 | A potentially unlimited number of tunnels may exist. In practice, only a few | |
1076 | tunnels are used during a period of time. Unused tunnels MUST, therefore, be | |
1077 | torn down. Detecting when tunnels are no longer in use is the subject of this section. | |
1078 | </t> | |
1079 | ||
1080 | <t> | |
1081 | There are two methods for removing tunnels: explicit deletion or expiry. | |
1082 | </t> | |
1083 | ||
1084 | <t> | |
1085 | Explicit deletion requires an IKE delete message. As the deletes | |
1086 | MUST be authenticated, both ends of the tunnel must maintain the | |
1087 | key channel (phase 1 ISAKMP SA). An implementation which refuses to either maintain or | |
1088 | recreate the keying channel SA will be unable to use this method. | |
1089 | </t> | |
1090 | ||
1091 | <t> | |
1092 | The tunnel expiry method simply allows the IKE daemon to | |
1093 | expire normally without attempting to re-key it. | |
1094 | </t> | |
1095 | ||
1096 | <t> | |
1097 | Regardless of which method is used to remove tunnels, the implementation MUST | |
1098 | a method to determine if the tunnel is still in use. The specifics are a | |
1099 | local matter, but the FreeS/WAN project uses the following criteria. These | |
1100 | criteria are currently implemented in the key management daemon, but could | |
1101 | also be implemented at the SPD layer using an idle timer. | |
1102 | </t> | |
1103 | ||
1104 | <t> | |
1105 | Set a short initial (soft) lifespan of 1 minute since many net flows last | |
1106 | only a few seconds. | |
1107 | </t> | |
1108 | ||
1109 | <t> | |
1110 | At the end of the lifespan, check to see if the tunnel was used by | |
1111 | traffic in either direction during the last 30 seconds. If so, assign a | |
1112 | longer tentative lifespan of 20 minutes after which, look again. If the | |
1113 | tunnel is not in use, then close the tunnel. | |
1114 | </t> | |
1115 | ||
1116 | <t> | |
1117 | The expiring state in the key management | |
1118 | system (see <xref target="expiring" />) implements these timeouts. | |
1119 | The timer above may be in the forwarding plane, | |
1120 | but then it must be re-settable. | |
1121 | </t> | |
1122 | ||
1123 | <t> | |
1124 | The tentative lifespan is independent of re-keying; it is just the time when | |
1125 | the tunnel's future is next considered. | |
1126 | (The term lifespan is used here rather than lifetime for this reason.) | |
1127 | Unlike re-keying, this tunnel use check is not costly and should happen | |
1128 | reasonably frequently. | |
1129 | </t> | |
1130 | ||
1131 | <t> | |
1132 | A multi-step back-off algorithm is not considered worth the effort here. | |
1133 | </t> | |
1134 | ||
1135 | <t> | |
1136 | If the security gateway and the client host are the | |
1137 | same and not a Bump-in-the-Stack or Bump-in-the-Wire implementation, tunnel | |
1138 | teardown decisions MAY pay attention to TCP connection status as reported | |
1139 | by the local TCP layer. A still-open TCP connection is almost a guarantee that more traffic is | |
1140 | expected. Closing of the only TCP connection through a tunnel is a | |
1141 | strong hint that no more traffic is expected. | |
1142 | </t> | |
1143 | ||
1144 | </section> <!-- "Aging" --> | |
1145 | ||
1146 | <section title="Teardown and cleanup"> | |
1147 | ||
1148 | <t> | |
1149 | Teardown should always be coordinated between the two ends of the tunnel by | |
1150 | interpreting and sending delete notifications. There is a | |
1151 | detailed sub-state in the expired connection state of the key manager that | |
1152 | relates to retransmits of the delete notifications, but this is considered to | |
1153 | be a keying system detail. | |
1154 | </t> | |
1155 | ||
1156 | <t> | |
1157 | On receiving a delete for the outbound SAs of a tunnel (or some subset of | |
1158 | them), tear down the inbound ones also and notify the remote end with a | |
1159 | delete. If the local system receives a delete for a tunnel which is no longer in | |
1160 | existence, then two delete messages have crossed paths. Ignore the delete. | |
1161 | The operation has already been completed. Do not generate any messages in this | |
1162 | situation. | |
1163 | </t> | |
1164 | <t> | |
1165 | Tunnels are to be considered as bidirectional entities, even though the | |
1166 | low-level protocols don't treat them this way. | |
1167 | </t> | |
1168 | ||
1169 | <t> | |
1170 | When the deletion is initiated locally, rather than as a | |
1171 | response to a received delete, send a delete for (all) the | |
1172 | inbound SAs of a tunnel. If the local system does not receive a responding delete | |
1173 | for the outbound SAs, try re-sending the original | |
1174 | delete. Three tries spaced 10 seconds apart seems a reasonable | |
1175 | level of effort. A failure of the other end to respond after 3 attempts, | |
1176 | indicates that the possibility of further communication is unlikely. Remove the outgoing SAs. | |
1177 | (The remote system may be a mobile node that is no longer present or powered on.) | |
1178 | </t> | |
1179 | ||
1180 | <t> | |
1181 | After re-keying, transmission should switch to using the new | |
1182 | outgoing SAs (ISAKMP or IPsec) immediately, and the old leftover | |
1183 | outgoing SAs should be cleared out promptly (delete should be sent | |
1184 | for the outgoing SAs) rather than waiting for them to expire. This | |
1185 | reduces clutter and minimizes confusion for the operator doing diagnostics. | |
1186 | </t> | |
1187 | ||
1188 | </section> | |
1189 | ||
1190 | </section> | |
1191 | ||
1192 | </section> <!-- "Specification" --> | |
1193 | ||
1194 | <section title="Impacts on IKE"> | |
1195 | ||
1196 | <section title="ISAKMP/IKE protocol"> | |
1197 | <t> | |
1198 | The IKE wire protocol needs no modifications. The major changes are | |
1199 | implementation issues relating to how the proposals are interpreted, and from | |
1200 | whom they may come. | |
1201 | </t> | |
1202 | <t> | |
1203 | As opportunistic encryption is designed to be useful between peers without | |
1204 | prior operator configuration, an IKE daemon must be prepared to negotiate | |
1205 | phase 1 SAs with any node. This may require a large amount of resources to | |
1206 | maintain cookie state, as well as large amounts of entropy for nonces, | |
1207 | cookies and so on. | |
1208 | </t> | |
1209 | <t> | |
1210 | The major changes to support opportunistic encryption are at the IKE daemon | |
1211 | level. These changes relate to handling of key acquisition requests, lookup | |
1212 | of public keys and TXT records, and interactions with firewalls and other | |
1213 | security facilities that may be co-resident on the same gateway. | |
1214 | </t> | |
1215 | </section> | |
1216 | ||
1217 | <section title="Gateway discovery process"> | |
1218 | <t> | |
1219 | In a typical configured tunnel, the address of SG-B is provided | |
1220 | via configuration. Furthermore, the mapping of an SPD entry to a gateway is | |
1221 | typically a 1:1 mapping. When the 0.0.0.0/0 SPD entry technique is used, then | |
1222 | the mapping to a gateway is determined by the reverse DNS records. | |
1223 | </t> | |
1224 | <t> | |
1225 | The need to do a DNS lookup and wait for a reply will typically introduce a | |
1226 | new state and a new event source (DNS replies) to IKE. Although a | |
1227 | synchronous DNS request can be implemented for proof of concept, experience | |
1228 | is that it can cause very high latencies when a queue of queries must | |
1229 | all timeout in series. | |
1230 | </t> | |
1231 | <t> | |
1232 | Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with | |
1233 | some of the protocol steps. | |
1234 | </t> | |
1235 | </section> | |
1236 | ||
1237 | <section title="Self identification"> | |
1238 | <t> | |
1239 | SG-A will have to establish its identity. Use an | |
1240 | IPv4 ID in phase 1. | |
1241 | </t> | |
1242 | <t> There are many situations where the administrator of SG-A may not be | |
1243 | able to control the reverse DNS records for SG-A's public IP address. | |
1244 | Typical situations include dialup connections and most residential-type broadband Internet access | |
1245 | (ADSL, cable-modem) connections. In these situations, a fully qualified domain | |
1246 | name that is under the control of SG-A's administrator may be used | |
1247 | when acting as an initiator only. | |
1248 | The FQDN ID should be used in phase 1. See <xref target="fqdn" /> | |
1249 | for more details and restrictions. | |
1250 | </t> | |
1251 | </section> | |
1252 | ||
1253 | <section title="Public key retrieval process"> | |
1254 | <t> | |
1255 | Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID or | |
1256 | an FQDN ID, an IKE daemon needs to examine local caches and | |
1257 | configuration files to determine if this is part of a configured tunnel. | |
1258 | If no configured tunnels are found, then the implementation should attempt to retrieve | |
1259 | a KEY record from the reverse DNS in the case of an IPv4/IPv6 ID, or | |
1260 | from the forward DNS in the case of FQDN ID. | |
1261 | </t> | |
1262 | <t> | |
1263 | It is reasonable that if other non-local sources of policy are used | |
1264 | (COPS, LDAP), they be consulted concurrently but some | |
1265 | clear ordering of policy be provided. Note that due to variances in | |
1266 | latency, implementations must wait for positive or negative replies from all sources | |
1267 | of policy before making any decisions. | |
1268 | </t> | |
1269 | </section> | |
1270 | ||
1271 | <section title="Interactions with DNSSEC"> | |
1272 | <t> | |
1273 | The implementation described (1.98) neither uses DNSSEC directly to | |
1274 | explicitly verify the authenticity of zone information, nor uses the NXT | |
1275 | records to provide authentication of the absence of a TXT or KEY | |
1276 | record. Rather, this implementation uses a trusted path to a DNSSEC | |
1277 | capable caching resolver. | |
1278 | </t> | |
1279 | <t> | |
1280 | To distinguish between an authenticated and an unauthenticated DNS | |
1281 | resource record, a stub resolver capable of returning DNSSEC | |
1282 | information MUST be used. | |
1283 | </t> | |
1284 | ||
1285 | </section> | |
1286 | ||
1287 | <!-- | |
1288 | <section title="Interactions with COPS"> | |
1289 | <t> | |
1290 | At this time there is no experience with implementations that interact | |
1291 | with COPS Policy Decision Points (PDP) <xref target="RFC2748" />. It is | |
1292 | suggested that it may be | |
1293 | appropriate for many of | |
1294 | the policy and discovery mechanisms outlined here to be done by a PDP. | |
1295 | In this context, the IKE daemon present in the Policy Enforcement Point | |
1296 | (PEP) may not need any modifications. | |
1297 | </t> | |
1298 | </section> | |
1299 | --> | |
1300 | ||
1301 | <section title="Required proposal types"> | |
1302 | ||
1303 | <section anchor="phase1id" title="Phase 1 parameters"> | |
1304 | <t> | |
1305 | Main mode MUST be used. | |
1306 | </t> | |
1307 | <t> | |
1308 | The initiator MUST offer at least one proposal using some combination | |
1309 | of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be | |
1310 | proposed first. | |
1311 | <xref target="RFC3526" /> | |
1312 | </t> | |
1313 | <t> | |
1314 | The initiator MAY offer additional proposals, but the cipher MUST not | |
1315 | be weaker than 3DES. The initiator SHOULD limit the number of proposals | |
1316 | such that the IKE datagrams do not need to be fragmented. | |
1317 | </t> | |
1318 | <t> | |
1319 | The responder MUST accept one of the proposals. If any configuration | |
1320 | of the responder is required then the responder is not acting in an | |
1321 | opportunistic way. | |
1322 | </t> | |
1323 | <t> | |
1324 | The initiator SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6) of the external | |
1325 | interface of the initiator for phase 1. (There is an exception, see <xref | |
1326 | target="fqdn" />.) The authentication method MUST be RSA public key signatures. | |
1327 | The RSA key for the initiator SHOULD be placed into a DNS KEY record in | |
1328 | the reverse space of the initiator (i.e. using in-addr.arpa or | |
1329 | ip6.arpa). | |
1330 | </t> | |
1331 | </section> | |
1332 | ||
1333 | <section anchor="phase2id" title="Phase 2 parameters"> | |
1334 | <t> | |
1335 | The initiator MUST propose a tunnel between the ultimate | |
1336 | sender ("Alice" or "A") and ultimate recipient ("Bob" or "B") | |
1337 | using 3DES-CBC | |
1338 | mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be specified. | |
1339 | </t> | |
1340 | <t> | |
1341 | Tunnel mode MUST be used. | |
1342 | </t> | |
1343 | <t> | |
1344 | Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32. | |
1345 | </t> | |
1346 | <t> | |
1347 | Authorization for the initiator to act on Alice's behalf is determined by | |
1348 | looking for a TXT record in the reverse-map at Alice's IP address. | |
1349 | </t> | |
1350 | <t> | |
1351 | Compression SHOULD NOT be mandatory. It MAY be offered as an option. | |
1352 | </t> | |
1353 | </section> | |
1354 | </section> | |
1355 | ||
1356 | </section> | |
1357 | ||
1358 | <section title="DNS issues"> | |
1359 | <section anchor="KEY" title="Use of KEY record"> | |
1360 | <t> | |
1361 | In order to establish their own identities, security gateways SHOULD publish | |
1362 | their public keys in their reverse DNS via | |
1363 | DNSSEC's KEY record. | |
1364 | See section 3 of <xref target="RFC2535">RFC 2535</xref>. | |
1365 | </t> | |
1366 | <t> | |
1367 | <preamble>For example:</preamble> | |
1368 | <artwork><![CDATA[ | |
1369 | KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8 | |
1370 | ]]></artwork> | |
1371 | ||
1372 | <list style="hanging"> | |
1373 | <t hangText="0x4200:"> The flag bits, indicating that this key is prohibited | |
1374 | for confidentiality use (it authenticates the peer only, a separate | |
1375 | Diffie-Hellman exchange is used for | |
1376 | confidentiality), and that this key is associated with the non-zone entity | |
1377 | whose name is the RR owner name. No other flags are set.</t> | |
1378 | <t hangText="4:">This indicates that this key is for use by IPsec.</t> | |
1379 | <t hangText="1:">An RSA key is present.</t> | |
1380 | <t hangText="AQNJjkKlIk9...nYyUkKK8:">The public key of the host as described in <xref target="RFC3110" />.</t> | |
1381 | </list> | |
1382 | </t> | |
1383 | <t>Use of several KEY records allows for key rollover. The SIG Payload in | |
1384 | IKE phase 1 SHOULD be accepted if the public key given by any KEY RR | |
1385 | validates it. | |
1386 | </t> | |
1387 | </section> | |
1388 | ||
1389 | <section anchor="TXT" title="Use of TXT delegation record"> | |
1390 | <t> | |
1391 | If, for example, machine Alice wishes SG-A to act on her behalf, then | |
1392 | she publishes a TXT record to provide authorization for SG-A to act on | |
1393 | Alice's behalf. Similarly for Bob and SG-B. | |
1394 | </t> | |
1395 | ||
1396 | <t> | |
1397 | These records are located in the reverse DNS (in-addr.arpa or ip6.arpa) for their | |
1398 | respective IP addresses. The reverse DNS SHOULD be secured by DNSSEC. | |
1399 | DNSSEC is required to defend against active attacks. | |
1400 | </t> | |
1401 | <t> | |
1402 | If Alice's address is P.Q.R.S, then she can authorize another node to | |
1403 | act on her behalf by publishing records at: | |
1404 | <artwork><![CDATA[ | |
1405 | S.R.Q.P.in-addr.arpa | |
1406 | ]]></artwork> | |
1407 | </t> | |
1408 | ||
1409 | <t> | |
1410 | The contents of the resource record are expected to be a string that | |
1411 | uses the following syntax, as suggested in <xref target="RFC1464">RFC1464</xref>. | |
1412 | (Note that the reply to query may include other TXT resource | |
1413 | records used by other applications.) | |
1414 | ||
1415 | <figure anchor="txtformat" title="Format of reverse delegation record"> | |
1416 | <artwork><![CDATA[ | |
1417 | X-IPsec-Server(P)=A.B.C.D KEY | |
1418 | ]]></artwork> | |
1419 | </figure> | |
1420 | </t> | |
1421 | ||
1422 | where the record is formed by the following fields: | |
1423 | ||
1424 | <list style="hanging"> | |
1425 | <t hangText="P:"> Specifies a precedence for this record. This is | |
1426 | similar to MX record preferences. Lower numbers have stronger | |
1427 | preference. | |
1428 | </t> | |
1429 | ||
1430 | <t hangText="A.B.C.D:"> Specifies the IP address of the Security Gateway | |
1431 | for this client machine. | |
1432 | </t> | |
1433 | ||
1434 | <t hangText="KEY:"> Is the encoded RSA Public key of the Security | |
1435 | Gateway. The key is provided here to avoid a second DNS lookup. If this | |
1436 | field is absent, then a KEY resource record should be looked up in the | |
1437 | reverse-map of A.B.C.D. The key is transmitted in base64 format. | |
1438 | </t> | |
1439 | </list> | |
1440 | ||
1441 | <t> | |
1442 | The fields of the record MUST be separated by whitespace. This | |
1443 | MAY be: space, tab, newline, or carriage return. A space is preferred. | |
1444 | </t> | |
1445 | ||
1446 | <t> | |
1447 | In the case where Alice is located at a public address behind a | |
1448 | security gateway that has no fixed address (or no control over its | |
1449 | reverse-map), then Alice may delegate to a public key by domain name. | |
1450 | ||
1451 | <figure anchor="txtfqdnformat" | |
1452 | title="Format of reverse delegation record (FQDN version)"> | |
1453 | <artwork><![CDATA[ | |
1454 | X-IPsec-Server(P)=@FQDN KEY | |
1455 | ]]></artwork> | |
1456 | </figure> | |
1457 | </t> | |
1458 | ||
1459 | <list style="hanging"> | |
1460 | <t hangText="P:"> Is as above. | |
1461 | </t> | |
1462 | ||
1463 | <t hangText="FQDN:"> Specifies the FQDN that the Security Gateway | |
1464 | will identify itself with. | |
1465 | </t> | |
1466 | ||
1467 | <t hangText="KEY:"> Is the encoded RSA Public key of the Security | |
1468 | Gateway. </t> | |
1469 | </list> | |
1470 | ||
1471 | <t> | |
1472 | If there is more than one such TXT record with strongest (lowest | |
1473 | numbered) precedence, one Security Gateway is picked arbitrarily from | |
1474 | those specified in the strongest-preference records. | |
1475 | </t> | |
1476 | ||
1477 | <section title="Long TXT records"> | |
1478 | <t> | |
1479 | When packed into transport format, TXT records which are longer than 255 | |
1480 | characters are divided into smaller <character-strings>. | |
1481 | (See <xref target="RFC1035" /> section 3.3 and 3.3.14.) These MUST | |
1482 | be reassembled into a single string for processing. | |
1483 | Whitespace characters in the base64 encoding are to be ignored. | |
1484 | </t> | |
1485 | </section> | |
1486 | ||
1487 | <section title="Choice of TXT record"> | |
1488 | <t> | |
1489 | It has been suggested to use the KEY, OPT, CERT, or KX records | |
1490 | instead of a TXT record. None is satisfactory. | |
1491 | </t> | |
1492 | <t> The KEY RR has a protocol field which could be used to indicate a new protocol, | |
1493 | and an algorithm field which could be used to | |
1494 | indicate different contents in the key data. However, the KEY record | |
1495 | is clearly not intended for storing what are really authorizations, | |
1496 | it is just for identities. Other uses have been discouraged. | |
1497 | </t> | |
1498 | <t> OPT resource records, as defined in <xref target="RFC2671" /> are not | |
1499 | intended to be used for storage of information. They are not to be loaded, | |
1500 | cached or forwarded. They are, therefore, inappropriate for use here. | |
1501 | </t> | |
1502 | <t> | |
1503 | CERT records <xref target="RFC2538" /> can encode almost any set of | |
1504 | information. A custom type code could be used permitting any suitable | |
1505 | encoding to be stored, not just X.509. According to | |
1506 | the RFC, the certificate RRs are to be signed internally which may add undesirable | |
1507 | and unnecessary bulk. Larger DNS records may require TCP instead of UDP transfers. | |
1508 | </t> | |
1509 | <t> | |
1510 | At the time of protocol design, the CERT RR was not widely deployed and | |
1511 | could not be counted upon. Use of CERT records will be investigated, | |
1512 | and may be proposed in a future revision of this document. | |
1513 | </t> | |
1514 | <t> | |
1515 | KX records are ideally suited for use instead of TXT records, but had not been deployed at | |
1516 | the time of implementation. | |
1517 | <!-- Jakob Schlyter <j@crt.se> confirmed --> | |
1518 | </t> | |
1519 | </section> | |
1520 | </section> | |
1521 | ||
1522 | <section anchor="fqdn" title="Use of FQDN IDs"> | |
1523 | <t> | |
1524 | Unfortunately, not every administrator has control over the contents | |
1525 | of the reverse-map. Where the initiator (SG-A) has no suitable reverse-map, the | |
1526 | authorization record present in the reverse-map of Alice may refer to a | |
1527 | FQDN instead of an IP address. | |
1528 | </t> | |
1529 | <t> | |
1530 | In this case, the client's TXT record gives the fully qualified domain | |
1531 | name (FQDN) in place of its security gateway's IP address. | |
1532 | The initiator should use the ID_FQDN ID-payload in phase 1. | |
1533 | A forward lookup for a KEY record on the FQDN must yield the | |
1534 | initiator's public key. | |
1535 | </t> | |
1536 | <t> | |
1537 | This method can also be used when the external address of SG-A is | |
1538 | dynamic. | |
1539 | </t> | |
1540 | <t> | |
1541 | If SG-A is acting on behalf of Alice, then Alice must still delegate | |
1542 | authority for SG-A to do so in her reverse-map. When Alice and SG-A | |
1543 | are one and the same (i.e. Alice is acting as an end-node) then there | |
1544 | is no need for this when initiating only. </t> | |
1545 | <t>However, Alice must still delegate to herself if she wishes others to | |
1546 | initiate OE to her. See <xref target="txtfqdnformat" />. | |
1547 | </t> | |
1548 | < | |
1549 | </section> | |
1550 | ||
1551 | <section title="Key roll-over"> | |
1552 | <t> | |
1553 | Good cryptographic hygiene says that one should replace public/private key pairs | |
1554 | periodically. Some administrators may wish to do this as often as daily. Typical DNS | |
1555 | propagation delays are determined by the SOA Resource Record MINIMUM | |
1556 | parameter, which controls how long DNS replies may be cached. For reasonable | |
1557 | operation of DNS servers, administrators usually want this value to be at least several | |
1558 | hours, sometimes as a long as a day. This presents a problem - a new key MUST | |
1559 | not be used prior to it propagating through DNS. | |
1560 | </t> | |
1561 | <t> | |
1562 | This problem is dealt with by having the Security Gateway generate a new | |
1563 | public/private key pair at least MINIMUM seconds in advance of using it. It | |
1564 | then adds this key to the DNS (both as a second KEY record and in additional TXT | |
1565 | delegation records) at key generation time. Note: only one key is allowed in | |
1566 | each TXT record. | |
1567 | </t> | |
1568 | <t> | |
1569 | When authenticating, all gateways MUST have available all public keys | |
1570 | that are found in DNS for this entity. This permits the authenticating end | |
1571 | to check both the key for "today" and the key for "tomorrow". Note that it is | |
1572 | the end which is creating the signature (possesses the private key) that | |
1573 | determines which key is to be used. | |
1574 | </t> | |
1575 | ||
1576 | </section> | |
1577 | </section> | |
1578 | ||
1579 | ||
1580 | <section title="Network address translation interaction"> | |
1581 | <t> | |
1582 | There are no fundamentally new issues for implementing opportunistic encryption | |
1583 | in the presence of network address translation. Rather there are | |
1584 | only the regular IPsec issues with NAT traversal. | |
1585 | </t> | |
1586 | <t> | |
1587 | There are several situations to consider for NAT. | |
1588 | </t> | |
1589 | <section title="Co-located NAT/NAPT"> | |
1590 | <t> | |
1591 | If a security gateway is also performing network address translation on | |
1592 | behalf of an end-system, then the packet should be translated prior to | |
1593 | being subjected to opportunistic encryption. This is in contrast to | |
1594 | typically configured tunnels which often exist to bridge islands of | |
1595 | private network address space. The security gateway will use the translated source | |
1596 | address for phase 2, and so the responding security gateway will look up that address to | |
1597 | confirm SG-A's authorization. | |
1598 | </t> | |
1599 | <t> In the case of NAT (1:1), the address space into which the | |
1600 | translation is done MUST be globally unique, and control over the | |
1601 | reverse-map is assumed. | |
1602 | Placing of TXT records is possible. | |
1603 | </t> | |
1604 | <t> In the case of NAPT (m:1), the address will be the security | |
1605 | gateway itself. The ability to get | |
1606 | KEY and TXT records in place will again depend upon whether or not | |
1607 | there is administrative control over the reverse-map. This is | |
1608 | identical to situations involving a single host acting on behalf of | |
1609 | itself. | |
1610 | ||
1611 | FQDN style can be used to get around a lack of a reverse-map for | |
1612 | initiators only. | |
1613 | </t> | |
1614 | </section> | |
1615 | ||
1616 | <section title="Security Gateway behind NAT/NAPT"> | |
1617 | <t> | |
1618 | If there is a NAT or NAPT between the security gateways, then normal IPsec | |
1619 | NAT traversal problems occur. In addition to the transport problem | |
1620 | which may be solved by other mechanisms, there is the issue of | |
1621 | what phase 1 and phase 2 IDs to use. While FQDN could | |
1622 | be used during phase 1 for the security gateway, there is no appropriate ID for phase 2. | |
1623 | Due to the NAT, the end systems live in different IP address spaces. | |
1624 | </t> | |
1625 | </section> | |
1626 | ||
1627 | <section title="End System is behind a NAT/NAPT"> | |
1628 | <t> | |
1629 | If the end system is behind a NAT (perhaps SG-B), then there is, in fact, no way for | |
1630 | another end system to address a packet to this end system. | |
1631 | Not only is opportunistic encryption | |
1632 | impossible, but it is also impossible for any communication to | |
1633 | be initiate to the end system. It may be possible for this end | |
1634 | system to initiate in such communication. This creates an asymmetry, but this is common for | |
1635 | NAPT. | |
1636 | </t> | |
1637 | </section> | |
1638 | </section> | |
1639 | ||
1640 | <section title="Host implementations"> | |
1641 | <t> | |
1642 | When Alice and SG-A are components of the same system, they are | |
1643 | considered to be a host implementation. The packet sequence scenario remains unchanged. | |
1644 | </t> | |
1645 | <t> | |
1646 | Components marked Alice are the upper layers (TCP, UDP, the | |
1647 | application), and SG-A is the IP layer. | |
1648 | </t> | |
1649 | <t> | |
1650 | Note that tunnel mode is still required. | |
1651 | </t> | |
1652 | <t> | |
1653 | As Alice and SG-A are acting on behalf of themselves, no TXT based delegation | |
1654 | record is necessary for Alice to initiate. She can rely on FQDN in a | |
1655 | forward map. This is particularly attractive to mobile nodes such as | |
1656 | notebook computers at conferences. | |
1657 | To respond, Alice/SG-A will still need an entry in Alice's reverse-map. | |
1658 | </t> | |
1659 | </section> | |
1660 | ||
1661 | <section title="Multi-homing"> | |
1662 | <t> | |
1663 | If there are multiple paths between Alice and Bob (as illustrated in | |
1664 | the diagram with SG-D), then additional DNS records are required to establish | |
1665 | authorization. | |
1666 | </t> | |
1667 | <t> | |
1668 | In <xref target="networkdiagram" />, Alice has two ways to | |
1669 | exit her network: SG-A and SG-D. Previously SG-D has been ignored. Postulate | |
1670 | that there are routers between Alice and her set of security gateways | |
1671 | (denoted by the + signs and the marking of an autonomous system number for | |
1672 | Alice's network). Datagrams may, therefore, travel to either SG-A or SG-D en | |
1673 | route to Bob. | |
1674 | </t> | |
1675 | <t> | |
1676 | As long as all network connections are in good order, it does not matter how | |
1677 | datagrams exit Alice's network. When they reach either security gateway, the | |
1678 | security gateway will find the TXT delegation record in Bob's reverse-map, | |
1679 | and establish an SA with SG-B. | |
1680 | </t> | |
1681 | <t> | |
1682 | SG-B has no problem establishing that either of SG-A or SG-D may speak for | |
1683 | Alice, because Alice has published two equally weighted TXT delegation records: | |
1684 | <figure anchor="txtmultiexample" | |
1685 | title="Multiple gateway delegation example for Alice"> | |
1686 | <artwork><![CDATA[ | |
1687 | X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== | |
1688 | X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9== | |
1689 | ]]></artwork> | |
1690 | </figure> | |
1691 | </t> | |
1692 | <t> | |
1693 | Alice's routers can now do any kind of load sharing needed. Both SG-A and SG-D send datagrams addressed to Bob through | |
1694 | their tunnel to SG-B. | |
1695 | </t> | |
1696 | <t> | |
1697 | Alice's use of non-equal weight delegation records to show preference of one gateway over another, has relevance only when SG-B | |
1698 | is initiating to Alice. | |
1699 | </t> | |
1700 | <t> | |
1701 | If the precedences are the same, then SG-B has a more difficult time. It | |
1702 | must decide which of the two tunnels to use. SG-B has no information about | |
1703 | which link is less loaded, nor which security gateway has more cryptographic | |
1704 | resources available. SG-B, in fact, has no knowledge of whether both gateways | |
1705 | are even reachable. | |
1706 | </t> | |
1707 | <t> | |
1708 | The Public Internet's default-free zone may well know a good route to Alice, | |
1709 | but the datagrams that SG-B creates must be addressed to either SG-A or SG-D; | |
1710 | they can not be addressed to Alice directly. | |
1711 | </t> | |
1712 | <t> | |
1713 | SG-B may make a number of choices: | |
1714 | <list style="numbers"> | |
1715 | <t>It can ignore the problem and round robin among the tunnels. This | |
1716 | causes losses during times when one or the other security gateway is | |
1717 | unreachable. If this worries Alice, she can change the weights in her | |
1718 | TXT delegation records.</t> | |
1719 | ||
1720 | <t>It can send to the gateway from which it most recently received datagrams. | |
1721 | This assumes that routing and reachability are symmetrical.</t> | |
1722 | ||
1723 | <t>It can listen to BGP information from the Internet to decide which | |
1724 | system is currently up. This is clearly much more complicated, but if SG-B is already participating | |
1725 | in the BGP peering system to announce Bob, the results data may already | |
1726 | be available to it. </t> | |
1727 | ||
1728 | <t>It can refuse to negotiate the second tunnel. (It is unclear whether or | |
1729 | not this is even an option.)</t> | |
1730 | ||
1731 | <t>It can silently replace the outgoing portion of the first tunnel with the | |
1732 | second one while still retaining the incoming portions of both. SG-B can, | |
1733 | thus, accept datagrams from either SG-A or SG-D, but | |
1734 | send only to the gateway that most recently re-keyed with it.</t> | |
1735 | </list> | |
1736 | </t> | |
1737 | ||
1738 | <t> | |
1739 | Local policy determines which choice SG-B makes. Note that even if SG-B has perfect | |
1740 | knowledge about the reachability of SG-A and SG-D, Alice may not be reachable | |
1741 | from either of these security gateways because of internal reachability | |
1742 | issues. | |
1743 | </t> | |
1744 | ||
1745 | <t> | |
1746 | FreeS/WAN implements option 5. Implementing a different option is | |
1747 | being considered. The multi-homing aspects of OE are not well developed and may | |
1748 | be the subject of a future document. | |
1749 | </t> | |
1750 | ||
1751 | </section> | |
1752 | ||
1753 | <section title="Failure modes"> | |
1754 | <section title="DNS failures"> | |
1755 | <t> | |
1756 | If a DNS server fails to respond, local policy decides | |
1757 | whether or not to permit communication in the clear as embodied in | |
1758 | the connection classes in <xref target="initclasses" />. | |
1759 | It is easy to mount a denial of service attack on the DNS server | |
1760 | responsible for a particular network's reverse-map. | |
1761 | Such an attack may cause all communication with that network to go in | |
1762 | the clear if the policy is permissive, or fail completely | |
1763 | if the policy is paranoid. Please note that this is an active attack. | |
1764 | </t> | |
1765 | <t> | |
1766 | There are still many networks | |
1767 | that do not have properly configured reverse-maps. Further, if the policy is not to communicate, | |
1768 | the above denial of service attack isolates the target network. Therefore, the decision of whether | |
1769 | or not to permit communication in the clear MUST be a matter of local policy. | |
1770 | </t> | |
1771 | </section> | |
1772 | ||
1773 | <section title="DNS configured, IKE failures"> | |
1774 | <t> | |
1775 | DNS records claim that opportunistic encryption should | |
1776 | occur, but the target gateway either does not respond on port 500, or | |
1777 | refuses the proposal. This may be because of a crash or reboot, a | |
1778 | faulty configuration, or a firewall filtering port 500. | |
1779 | </t> | |
1780 | <t> | |
1781 | The receipt of ICMP port, host or network unreachable | |
1782 | messages indicates a potential problem, but MUST NOT cause communication | |
1783 | to fail | |
1784 | immediately. ICMP messages are easily forged by attackers. If such a | |
1785 | forgery caused immediate failure, then an active attacker could easily | |
1786 | prevent any | |
1787 | encryption from ever occurring, possibly preventing all communication. | |
1788 | </t> | |
1789 | <t> | |
1790 | In these situations a clear log should be produced | |
1791 | and local policy should dictate if communication is then | |
1792 | permitted in the clear. | |
1793 | </t> | |
1794 | </section> | |
1795 | ||
1796 | <section title="System reboots"> | |
1797 | <t> | |
1798 | Tunnels sometimes go down because the remote end crashes, | |
1799 | disconnects, or has a network link break. In general there is no | |
1800 | notification of this. Even in the event of a crash and successful reboot, | |
1801 | other SGs don't hear about it unless the rebooted SG has specific | |
1802 | reason to talk to them immediately. Over-quick response to temporary | |
1803 | network outages is undesirable. Note that a tunnel can be torn | |
1804 | down and then re-established without any effect visible to the user | |
1805 | except a pause in traffic. On the other hand, if one end reboots, | |
1806 | the other end can't get datagrams to it at all (except via | |
1807 | IKE) until the situation is noticed. So a bias toward quick | |
1808 | response is appropriate even at the cost of occasional | |
1809 | false alarms. | |
1810 | </t> | |
1811 | ||
1812 | <t> | |
1813 | A mechanism for recovery after reboot is a topic of current research and is not specified in this | |
1814 | document. | |
1815 | </t> | |
1816 | ||
1817 | <t> | |
1818 | A deliberate shutdown should include an attempt, using deletes, to notify all other SGs | |
1819 | currently connected by phase 1 SAs that communication is | |
1820 | about to fail. Again, a remote SG will assume this is a teardown. Attempts by the | |
1821 | remote SGs to negotiate new tunnels as replacements should be ignored. When possible, | |
1822 | SGs should attempt to preserve information about currently-connected SGs in non-volatile storage, so | |
1823 | that after a crash, an Initial-Contact can be sent to previous partners to | |
1824 | indicate loss of all previously established connections. | |
1825 | </t> | |
1826 | ||
1827 | </section> | |
1828 | </section> | |
1829 | ||
1830 | <!-- | |
1831 | <section title="Performance experiences"> | |
1832 | ||
1833 | Claudia> Is it useful to point out (or to clarify for our own discussion) any of the | |
1834 | Claudia> following: | |
1835 | ||
1836 | Claudia> * how much time this is likely to take on typical current hardware? | |
1837 | Claudia> * what steps are likely to be time consuming | |
1838 | Claudia> * how any added time could affect a typical transaction, such as hitting | |
1839 | Claudia> a web site | |
1840 | Claudia> * any ways to minimize such time delays | |
1841 | ||
1842 | <section title="Introduced latency"> | |
1843 | </section> | |
1844 | ||
1845 | <section title="Cryptographic performance"> | |
1846 | </section> | |
1847 | ||
1848 | <section title="Phase 1 SA performance"> | |
1849 | </section> | |
1850 | ||
1851 | </section> | |
1852 | --> | |
1853 | ||
1854 | <section title="Unresolved issues"> | |
1855 | <section title="Control of reverse DNS"> | |
1856 | <t> | |
1857 | The method of obtaining information by reverse DNS lookup causes | |
1858 | problems for people who cannot control their reverse DNS | |
1859 | bindings. This is an unresolved problem in this version, and is out | |
1860 | of scope. | |
1861 | </t> | |
1862 | </section> | |
1863 | </section> | |
1864 | ||
1865 | <section title="Examples"> | |
1866 | ||
1867 | <section title="Clear-text usage (permit policy)"> | |
1868 | ||
1869 | <t> | |
1870 | Two example scenarios follow. In the first example GW-A | |
1871 | (Gateway A) and GW-B (Gateway B) have always-clear-text policies, and in the second example they have an OE | |
1872 | policy. The clear-text policy serves as a reference for what occurs in | |
1873 | TCP/IP in the absence of Opportunistic Encryption. | |
1874 | ||
1875 | <t> | |
1876 | Alice wants to communicate with Bob. Perhaps she wants to retrieve a | |
1877 | web page from Bob's web server. In the absence of opportunistic | |
1878 | encryptors, the following events occur: | |
1879 | </t> | |
1880 | ||
1881 | <figure anchor="regulartiming" title="Timing of regular transaction"> | |
1882 | <artwork><![CDATA[ | |
1883 | Alice SG-A DNS SG-B Bob | |
1884 | Human or application | |
1885 | 'clicks' with a name. | |
1886 | (1) | |
1887 | ||
1888 | ------(2)--------------> | |
1889 | Application looks up | |
1890 | name in DNS to get | |
1891 | IP address. | |
1892 | ||
1893 | <-----(3)--------------- | |
1894 | Resolver returns "A" RR | |
1895 | to application with IP | |
1896 | address. | |
1897 | ||
1898 | (4) | |
1899 | Application starts a TCP session | |
1900 | or UDP session and OS sends | |
1901 | first datagram | |
1902 | ||
1903 | ----(5)-----> | |
1904 | Datagram is seen at first gateway | |
1905 | from Alice (SG-A). | |
1906 | ||
1907 | ----------(6)------> | |
1908 | Datagram traverses | |
1909 | network. | |
1910 | ||
1911 | ------(7)-----> | |
1912 | Datagram arrives | |
1913 | at Bob, is provided | |
1914 | to TCP. | |
1915 | ||
1916 | <------(8)------ | |
1917 | A reply is sent. | |
1918 | ||
1919 | <----------(9)------ | |
1920 | Datagram traverses | |
1921 | network. | |
1922 | <----(10)----- | |
1923 | Alice receives | |
1924 | answer. | |
1925 | ||
1926 | (11)-----------> | |
1927 | A second exchange | |
1928 | occurs. | |
1929 | ----------(12)-----> | |
1930 | --------------> | |
1931 | <--------------- | |
1932 | <------------------- | |
1933 | <------------- | |
1934 | ]]></artwork> | |
1935 | </figure> | |
1936 | ||
1937 | </t> | |
1938 | </section> | |
1939 | ||
1940 | <section title="Opportunistic encryption"> | |
1941 | ||
1942 | <t> | |
1943 | In the presence of properly configured opportunistic encryptors, the | |
1944 | event list is extended. Only changes are annotated. | |
1945 | </t> | |
1946 | ||
1947 | <t>The following symbols are used in the time-sequence diagram</t> | |
1948 | ||
1949 | <t> | |
1950 | <list style="hanging"> | |
1951 | <t hangText="-"> A single dash represents clear-text datagrams.</t> | |
1952 | <t hangText="="> An equals sign represents phase 2 (IPsec) cipher-text | |
1953 | datagrams.</t> | |
1954 | <t hangText="~"> A single tilde represents clear-text phase 1 datagrams.</t> | |
1955 | <t hangText="#"> A hash sign represents phase 1 (IKE) cipher-text | |
1956 | datagrams.</t> | |
1957 | </list> | |
1958 | </t> | |
1959 | ||
1960 | <t> | |
1961 | <figure anchor="opportunistictiming" title="Timing of opportunistic encryption transaction"> | |
1962 | <artwork><![CDATA[ | |
1963 | Alice SG-A DNS SG-B Bob | |
1964 | (1) | |
1965 | ------(2)--------------> | |
1966 | <-----(3)--------------- | |
1967 | (4)----(5)----->+ | |
1968 | SG-A sees datagram | |
1969 | to new target and | |
1970 | saves it as "first" | |
1971 | ||
1972 | ----(5B)-> | |
1973 | SG-A asks DNS | |
1974 | for TXT RR. | |
1975 | ||
1976 | <---(5C)-- | |
1977 | DNS returns TXT RR. | |
1978 | ||
1979 | ~~~~~~~~~~~~~(5D)~~~> | |
1980 | initial IKE main mode | |
1981 | packet is sent. | |
1982 | ||
1983 | <~~~~~~~~~~~~(5E1)~~~ | |
1984 | ~~~~~~~~~~~~~(5E2)~~> | |
1985 | <~~~~~~~~~~~~(5E3)~~~ | |
1986 | IKE phase 1 - privacy. | |
1987 | ||
1988 | #############(5E4)##> | |
1989 | SG-A sends ID to SG-B | |
1990 | <----(5F1)-- | |
1991 | SG-B asks DNS | |
1992 | for SG-A's public | |
1993 | KEY | |
1994 | -----(5F2)-> | |
1995 | DNS provides KEY RR. | |
1996 | SG-B authenticates SG-A | |
1997 | ||
1998 | <############(5E5)### | |
1999 | IKE phase 1 - complete | |
2000 | ||
2001 | #############(5G1)##> | |
2002 | IKE phase 2 - Alice<->Bob | |
2003 | tunnel is proposed. | |
2004 | ||
2005 | <----(5H1)-- | |
2006 | SG-B asks DNS for | |
2007 | Alice's TXT record. | |
2008 | -----(5H2)-> | |
2009 | DNS replies with TXT | |
2010 | record. SG-B checks | |
2011 | SG-A's authorization. | |
2012 | ||
2013 | <############(5G2)### | |
2014 | SG-B accepts proposal. | |
2015 | ||
2016 | #############(5G3)##> | |
2017 | SG-A confirms. | |
2018 | ||
2019 | ============(6)====> | |
2020 | SG-A sends "first" | |
2021 | packet in new IPsec | |
2022 | SA. | |
2023 | ------(7)-----> | |
2024 | packet is decrypted | |
2025 | and forward to Bob. | |
2026 | <------(8)------ | |
2027 | <==========(9)====== | |
2028 | return packet also | |
2029 | encrypted. | |
2030 | <-----(10)---- | |
2031 | ||
2032 | (11)-----------> | |
2033 | a second packet | |
2034 | is sent by Alice | |
2035 | ==========(12)=====> | |
2036 | existing tunnel is used | |
2037 | --------------> | |
2038 | <--------------- | |
2039 | <=================== | |
2040 | <------------- | |
2041 | ]]></artwork> | |
2042 | </figure> | |
2043 | ||
2044 | </t> | |
2045 | ||
2046 | <t> | |
2047 | For the purposes of this section, we will describe only the changes that | |
2048 | occur between <xref target="regulartiming" /> and | |
2049 | <xref target="opportunistictiming" />. This corresponds to time points 5, 6, 7, 9 and 10 on the list above. | |
2050 | </t> | |
2051 | ||
2052 | <list style="symbols"> | |
2053 | <t> | |
2054 | At point (5), SG-A intercepts the datagram because this source/destination pair lacks a policy | |
2055 | (the non-existent policy state). SG-A creates a hold policy, and buffers the datagram. SG-A requests keys from the keying daemon. | |
2056 | </t> | |
2057 | ||
2058 | <t> | |
2059 | SG-A's IKE daemon, having looked up the source/destination pair in the connection | |
2060 | class list, creates a new Potential OE connection instance. SG-A starts DNS | |
2061 | queries. | |
2062 | </t> | |
2063 | </section> | |
2064 | ||
2065 | <section title="(5C) DNS returns TXT record(s)"> | |
2066 | ||
2067 | <t> | |
2068 | DNS returns properly formed TXT delegation records, and SG-A's IKE daemon | |
2069 | causes this instance to make a transition from Potential OE connection to Pending OE | |
2070 | connection. | |
2071 | </t> | |
2072 | ||
2073 | <t> | |
2074 | Using the example above, the returned record might contain: | |
2075 | ||
2076 | <figure anchor="txtexample" | |
2077 | title="Example of reverse delegation record for Bob"> | |
2078 | <artwork><![CDATA[ | |
2079 | X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== | |
2080 | ]]></artwork> | |
2081 | </figure> | |
2082 | with SG-B's IP address and public key listed. | |
2083 | </t> | |
2084 | ||
2085 | </section> | |
2086 | ||
2087 | <section title="(5D) Initial IKE main mode packet goes out"> | |
2088 | <t>Upon entering Pending OE connection, SG-A sends the initial ISAKMP | |
2089 | message with proposals. See <xref target="phase1id" />. | |
2090 | </t> | |
2091 | </section> | |
2092 | ||
2093 | <section title="(5E1) Message 2 of phase 1 exchange"> | |
2094 | <t> | |
2095 | SG-B receives the message. A new connection instance is created in the | |
2096 | unauthenticated OE peer state. | |
2097 | </t> | |
2098 | </section> | |
2099 | ||
2100 | <section title="(5E2) Message 3 of phase 1 exchange"> | |
2101 | <t> | |
2102 | SG-A sends a Diffie-Hellman exponent. This is an internal state of the | |
2103 | keying daemon. | |
2104 | </t> | |
2105 | </section> | |
2106 | ||
2107 | <section title="(5E3) Message 4 of phase 1 exchange"> | |
2108 | <t> | |
2109 | SG-B responds with a Diffie-Hellman exponent. This is an internal state of the | |
2110 | keying protocol. | |
2111 | </t> | |
2112 | </section> | |
2113 | ||
2114 | <section title="(5E4) Message 5 of phase 1 exchange"> | |
2115 | <t> | |
2116 | SG-A uses the phase 1 SA to send its identity under encryption. | |
2117 | The choice of identity is discussed in <xref target="phase1id" />. | |
2118 | This is an internal state of the keying protocol. | |
2119 | </t> | |
2120 | </section> | |
2121 | ||
2122 | <section title="(5F1) Responder lookup of initiator key"> | |
2123 | <t> | |
2124 | SG-B asks DNS for the public key of the initiator. | |
2125 | DNS looks for a KEY record by IP address in the reverse-map. | |
2126 | That is, a KEY resource record is queried for 4.1.1.192.in-addr.arpa | |
2127 | (recall that SG-A's external address is 192.1.1.4). | |
2128 | SG-B uses the resulting public key to authenticate the initiator. See <xref | |
2129 | target="KEY" /> for further details. | |
2130 | </t> | |
2131 | </section> | |
2132 | ||
2133 | <section title="(5F2) DNS replies with public key of initiator"> | |
2134 | <t> | |
2135 | Upon successfully authenticating the peer, the connection instance makes a | |
2136 | transition to authenticated OE peer on SG-B. | |
2137 | </t> | |
2138 | <t> | |
2139 | The format of the TXT record returned is described in | |
2140 | <xref target="TXT" />. | |
2141 | </t> | |
2142 | </section> | |
2143 | ||
2144 | <section title="(5E5) Responder replies with ID and authentication"> | |
2145 | <t> | |
2146 | SG-B sends its ID along with authentication material. This is an internal | |
2147 | state for the keying protocol. | |
2148 | </t> | |
2149 | </section> | |
2150 | ||
2151 | <section title="(5G) IKE phase 2"> | |
2152 | <section title="(5G1) Initiator proposes tunnel"> | |
2153 | <t> | |
2154 | Having established mutually agreeable authentications (via KEY) and | |
2155 | authorizations (via TXT), SG-A proposes to create an IPsec tunnel for | |
2156 | datagrams transiting from Alice to Bob. This tunnel is established only for | |
2157 | the Alice/Bob combination, not for any subnets that may be behind SG-A and SG-B. | |
2158 | </t> | |
2159 | </section> | |
2160 | ||
2161 | <section title="(5H1) Responder determines initiator's authority"> | |
2162 | <t> | |
2163 | While the identity of SG-A has been established, its authority to | |
2164 | speak for Alice has not yet been confirmed. SG-B does a reverse | |
2165 | lookup on Alice's address for a TXT record. | |
2166 | </t> | |
2167 | <t>Upon receiving this specific proposal, SG-B's connection instance | |
2168 | makes a transition into the potential OE connection state. SG-B may already have an | |
2169 | instance, and the check is made as described above.</t> | |
2170 | </section> | |
2171 | ||
2172 | <section title="(5H2) DNS replies with TXT record(s)"> | |
2173 | <t> | |
2174 | The returned key and IP address should match that of SG-A. | |
2175 | </t> | |
2176 | </section> | |
2177 | ||
2178 | <section title="(5G2) Responder agrees to proposal"> | |
2179 | <t> | |
2180 | Should additional communication occur between, for instance, Dave and Bob using | |
2181 | SG-A and SG-B, a new tunnel (phase 2 SA) would be established. The phase 1 SA | |
2182 | may be reusable. | |
2183 | </t> | |
2184 | <t>SG-A, having successfully keyed the tunnel, now makes a transition from | |
2185 | Pending OE connection to Keyed OE connection. | |
2186 | </t> | |
2187 | <t>The responder MUST setup the inbound IPsec SAs before sending its reply.</t> | |
2188 | </section> | |
2189 | ||
2190 | <section title="(5G3) Final acknowledgment from initiator"> | |
2191 | <t> | |
2192 | The initiator agrees with the responder's choice and sets up the tunnel. | |
2193 | The initiator sets up the inbound and outbound IPsec SAs. | |
2194 | </t> | |
2195 | <t> | |
2196 | The proper authorization returned with keys prompts SG-B to make a transition | |
2197 | to the keyed OE connection state. | |
2198 | </t> | |
2199 | <t>Upon receipt of this message, the responder may now setup the outbound | |
2200 | IPsec SAs.</t> | |
2201 | </section> | |
2202 | </section> | |
2203 | ||
2204 | <section title="(6) IPsec succeeds, and sets up tunnel for communication between Alice and Bob"> | |
2205 | <t> | |
2206 | SG-A sends the datagram saved at step (5) through the newly created | |
2207 | tunnel to SG-B, where it gets decrypted and forwarded. | |
2208 | Bob receives it at (7) and replies at (8). | |
2209 | </t> | |
2210 | </section> | |
2211 | ||
2212 | <section title="(9) SG-B already has tunnel up with G1 and uses it"> | |
2213 | <t> | |
2214 | At (9), SG-B has already established an SPD entry mapping Bob->Alice via a | |
2215 | tunnel, so this tunnel is simply applied. The datagram is encrypted to SG-A, | |
2216 | decrypted by SG-A and passed to Alice at (10). | |
2217 | </t> | |
2218 | ||
2219 | </section> | |
2220 | </section> <!-- OE example --> | |
2221 | ||
2222 | </section> <!-- Examples --> | |
2223 | ||
2224 | <section anchor="securityconsiderations" title="Security considerations"> | |
2225 | ||
2226 | <section title="Configured vs opportunistic tunnels"> | |
2227 | <t> | |
2228 | Configured tunnels are those which are setup using bilateral mechanisms: exchanging | |
2229 | public keys (raw RSA, DSA, PKIX), pre-shared secrets, or by referencing keys that | |
2230 | are in known places (distinguished name from LDAP, DNS). These keys are then used to | |
2231 | configure a specific tunnel. | |
2232 | </t> | |
2233 | <t> | |
2234 | A pre-configured tunnel may be on all the time, or may be keyed only when needed. | |
2235 | The end points of the tunnel are not necessarily static: many mobile | |
2236 | applications (road warrior) are considered to be configured tunnels. | |
2237 | </t> | |
2238 | <t> | |
2239 | The primary characteristic is that configured tunnels are assigned specific | |
2240 | security properties. They may be trusted in different ways relating to exceptions to | |
2241 | firewall rules, exceptions to NAT processing, and to bandwidth or other quality of service restrictions. | |
2242 | </t> | |
2243 | <t> | |
2244 | Opportunistic tunnels are not inherently trusted in any strong way. They are | |
2245 | created without prior arrangement. As the two parties are strangers, there | |
2246 | MUST be no confusion of datagrams that arrive from opportunistic peers and | |
2247 | those that arrive from configured tunnels. A security gateway MUST take care | |
2248 | that an opportunistic peer can not impersonate a configured peer. | |
2249 | </t> | |
2250 | <t> | |
2251 | Ingress filtering MUST be used to make sure that only datagrams authorized by | |
2252 | negotiation (and the concomitant authentication and authorization) are | |
2253 | accepted from a tunnel. This is to prevent one peer from impersonating another. | |
2254 | </t> | |
2255 | <t> | |
2256 | An implementation suggestion is to treat opportunistic tunnel | |
2257 | datagrams as if they arrive on a logical interface distinct from other | |
2258 | configured tunnels. As the number of opportunistic tunnels that may be | |
2259 | created automatically on a system is potentially very high, careful attention | |
2260 | to scaling should be taken into account. | |
2261 | </t> | |
2262 | <t> | |
2263 | As with any IKE negotiation, opportunistic encryption cannot be secure | |
2264 | without authentication. Opportunistic encryption relies on DNS for its | |
2265 | authentication information and, therefore, cannot be fully secure without | |
2266 | a secure DNS. Without secure DNS, opportunistic encryption can protect against passive | |
2267 | eavesdropping but not against active man-in-the-middle attacks. | |
2268 | </t> | |
2269 | </section> | |
2270 | ||
2271 | <section title="Firewalls versus Opportunistic Tunnels"> | |
2272 | <t> | |
2273 | Typical usage of per datagram access control lists is to implement various | |
2274 | kinds of security gateways. These are typically called "firewalls". | |
2275 | </t> | |
2276 | <t> | |
2277 | Typical usage of a virtual private network (VPN) within a firewall is to | |
2278 | bypass all or part of the access controls between two networks. Additional | |
2279 | trust (as outlined in the previous section) is given to datagrams that arrive | |
2280 | in the VPN. | |
2281 | </t> | |
2282 | <t> | |
2283 | Datagrams that arrive via opportunistically configured tunnels MUST not be | |
2284 | trusted. Any security policy that would apply to a datagram arriving in the | |
2285 | clear SHOULD also be applied to datagrams arriving opportunistically. | |
2286 | </t> | |
2287 | </section> | |
2288 | ||
2289 | <section title="Denial of service"> | |
2290 | <t> | |
2291 | There are several different forms of denial of service that an implementor | |
2292 | should concern themselves with. Most of these problems are shared with | |
2293 | security gateways that have large numbers of mobile peers (road warriors). | |
2294 | </t> | |
2295 | <t> | |
2296 | The design of ISAKMP/IKE, and its use of cookies, defend against many kinds | |
2297 | of denial of service. Opportunism changes the assumption that if the phase 1 (ISAKMP) | |
2298 | SA is authenticated, that it was worthwhile creating. Because the gateway will communicate with any machine, it is | |
2299 | possible to form phase 1 SAs with any machine on the Internet. | |
2300 | </t> | |
2301 | ||
2302 | </section> | |
2303 | </section> | |
2304 | ||
2305 | <section title="IANA Considerations"> | |
2306 | <t> | |
2307 | There are no known numbers which IANA will need to manage. | |
2308 | </t> | |
2309 | </section> | |
2310 | ||
2311 | <section title="Acknowledgments"> | |
2312 | <t> | |
2313 | Substantive portions of this document are based upon previous work by | |
2314 | Henry Spencer. | |
2315 | </t> | |
2316 | <t> | |
2317 | Thanks to Tero Kivinen, Sandy Harris, Wes Hardarker, Robert Moskowitz, | |
2318 | Jakob Schlyter, Bill Sommerfeld, John Gilmore and John Denker for their | |
2319 | comments and constructive criticism. | |
2320 | </t> | |
2321 | <t> | |
2322 | Sandra Hoffman and Bill Dickie did the detailed proof reading and editing. | |
2323 | </t> | |
2324 | </section> | |
2325 | ||
2326 | </middle> | |
2327 | ||
2328 | <back> | |
2329 | <references title="Normative references"> | |
2330 | <?rfc include="reference.OEspec" ?> | |
2331 | <!-- renumber according to reference order --> | |
2332 | <?rfc include="reference.RFC.0791" ?> | |
2333 | <?rfc include="reference.RFC.1009" ?> | |
2334 | <?rfc include="reference.RFC.1984" ?> | |
2335 | <?rfc include="reference.RFC.2119" ?> | |
2336 | <!-- IPsec --> | |
2337 | <?rfc include="reference.RFC.2367" ?> | |
2338 | <?rfc include="reference.RFC.2401" ?> | |
2339 | <?rfc include="reference.RFC.2407" ?> | |
2340 | <?rfc include="reference.RFC.2408" ?> | |
2341 | <?rfc include="reference.RFC.2409" ?> | |
2342 | <!-- MODPGROUPS --> | |
2343 | <?rfc include="reference.RFC.3526" ?> | |
2344 | <!-- DNSSEC --> | |
2345 | <?rfc include="reference.RFC.1034" ?> | |
2346 | <?rfc include="reference.RFC.1035" ?> | |
2347 | <?rfc include="reference.RFC.2671" ?> | |
2348 | <?rfc include="reference.RFC.1464" ?> | |
2349 | <?rfc include="reference.RFC.2535" ?> | |
2350 | <?rfc include="reference.RFC.3110" ?> | |
2351 | <?rfc include="reference.RFC.2538" ?> | |
2352 | <!-- COPS --> | |
2353 | <?rfc include="reference.RFC.2748" ?> | |
2354 | <!-- NAT --> | |
2355 | <?rfc include="reference.RFC.2663" ?> | |
2356 | </references> | |
2357 | <!-- <references title="Non-normative references"> --> | |
2358 | <!-- ESPUDP --> | |
2359 | <!-- <?rfc include="reference.ESPUDP" ?> --> | |
2360 | <!-- </references> --> | |
2361 | </back> | |
2362 | </rfc> | |
2363 | <!-- | |
2364 | $Id: draft-richardson-ipsec-opportunistic.xml,v 1.1 2004/03/15 20:35:24 as Exp $ | |
2365 | ||
2366 | $Log: draft-richardson-ipsec-opportunistic.xml,v $ | |
2367 | Revision 1.1 2004/03/15 20:35:24 as | |
2368 | added files from freeswan-2.04-x509-1.5.3 | |
2369 | ||
2370 | Revision 1.33 2003/06/30 03:19:59 mcr | |
2371 | timing-diagram with inline explanation. | |
2372 | ||
2373 | Revision 1.32 2003/06/30 01:57:44 mcr | |
2374 | initial edits per-Bob Braden. | |
2375 | ||
2376 | Revision 1.31 2003/05/26 19:31:23 mcr | |
2377 | updates to drafts - IPSEC RR - SC versions, and RFC3526 | |
2378 | reference in OE draft. | |
2379 | ||
2380 | Revision 1.30 2003/05/21 15:42:34 mcr | |
2381 | updates due to publication of RFC 3526. | |
2382 | ||
2383 | Revision 1.29 2003/01/17 16:22:55 mcr | |
2384 | rev 11 of OE draft. | |
2385 | ||
2386 | Revision 1.28 2002/07/25 19:27:31 mcr | |
2387 | added DHR's minor edits. | |
2388 | ||
2389 | Revision 1.27 2002/07/21 16:26:26 mcr | |
2390 | slides from presentation at OLS | |
2391 | draft-10 of OE draft. | |
2392 | ||
2393 | Revision 1.26 2002/07/16 03:46:53 mcr | |
2394 | second edits from Sandra. | |
2395 | ||
2396 | Revision 1.25 2002/07/16 03:36:14 mcr | |
2397 | removed HS from authors list | |
2398 | updated reference inclusion to use <?rfc-include directive. | |
2399 | Revision 1.24 2002/07/11 02:08:21 mcr | |
2400 | updated XML file from Sandra | |
2401 | ||
2402 | Revision 1.23 2002/06/06 17:18:53 mcr | |
2403 | spellcheck. | |
2404 | ||
2405 | Revision 1.22 2002/06/06 17:14:19 mcr | |
2406 | results of hand-editing session from May 28th. | |
2407 | This is FINAL OE draft. | |
2408 | ||
2409 | Revision 1.21 2002/06/06 02:25:44 mcr | |
2410 | results of hand-editing session from May 28th. | |
2411 | This is FINAL OE draft. | |
2412 | ||
2413 | Revision 1.20 2002/05/24 03:28:37 mcr | |
2414 | changes as requested by RFC editor. | |
2415 | ||
2416 | Revision 1.19 2002/04/09 16:01:05 mcr | |
2417 | comments from PHB. | |
2418 | ||
2419 | Revision 1.18 2002/04/08 02:14:34 mcr | |
2420 | RGBs changes to rev6. | |
2421 | ||
2422 | Revision 1.17 2002/03/12 21:23:55 mcr | |
2423 | adjusted definition of default-free zone. | |
2424 | moved text on key rollover from format description to new | |
2425 | section. | |
2426 | ||
2427 | Revision 1.16 2002/02/22 01:23:21 mcr | |
2428 | revisions from MCR (2002/2/18) and net. | |
2429 | ||
2430 | Revision 1.15 2002/02/21 20:44:12 mcr | |
2431 | extensive from DHR. | |
2432 | ||
2433 | Revision 1.14 2002/02/10 16:20:39 mcr | |
2434 | -05 draft. Many revisions to do "OE system in world of OE systems" | |
2435 | view of the universe. | |
2436 | ||
2437 | Revision 1.13 2001/12/20 04:35:22 mcr | |
2438 | fixed reference to rfc1984. | |
2439 | ||
2440 | Revision 1.12 2001/12/20 03:35:19 mcr | |
2441 | comments from Henry, Tero, and Sandy. | |
2442 | ||
2443 | Revision 1.11 2001/12/19 07:26:22 mcr | |
2444 | added comment about KX records. | |
2445 | ||
2446 | Revision 1.10 2001/11/09 04:28:10 mcr | |
2447 | fixed some typos with XML, and one s/SG-B/SG-D/. | |
2448 | ||
2449 | Revision 1.9 2001/11/09 04:07:13 mcr | |
2450 | expanded section 10: multihoming, with an example. | |
2451 | ||
2452 | Revision 1.8 2001/11/09 02:16:51 mcr | |
2453 | added lifetime/lifespan definitions. | |
2454 | moved example from 5B to 5C. | |
2455 | added reference to phase 1 IDs to 5D. | |
2456 | cleared up text in aging section. | |
2457 | added text about delegation of DNSSEC activity to a DNS server. | |
2458 | spelt out DH group names. | |
2459 | added text about ignoring TXT records unless DNSSEC is deployed (somerfeld) | |
2460 | added example of TXT delegation using FQDN. | |
2461 | clarified some text in NAT interaction section. | |
2462 | clarified absense of TXT record need for host implementation | |
2463 | ||
2464 | Revision 1.7 2001/11/08 23:09:37 mcr | |
2465 | changed revision of draft to 03. | |
2466 | ||
2467 | Revision 1.6 2001/11/08 19:37:14 mcr | |
2468 | fixed some formatting of Aging section. | |
2469 | ||
2470 | Revision 1.5 2001/11/08 19:19:30 mcr | |
2471 | fixed address for DHR, updated address for MCR, | |
2472 | added reference to original HS/DHR OE specification paper. | |
2473 | ||
2474 | Revision 1.4 2001/11/08 19:08:24 mcr | |
2475 | section 10, "Renewal and Teardown" added moved between 4/5, and | |
2476 | slightly rewritten. | |
2477 | ||
2478 | Revision 1.3 2001/11/08 18:56:34 mcr | |
2479 | sections 4.2, 5.6, 5.7.1 and 6.2 edited as per HS. | |
2480 | section 10, "Renewal and Teardown" added. | |
2481 | section 11, "Failure modes" completed. | |
2482 | ||
2483 | Revision 1.2 2001/11/05 20:31:31 mcr | |
2484 | added section from OE spec on aging and teardown. | |
2485 | ||
2486 | Revision 1.1 2001/11/05 04:27:58 mcr | |
2487 | OE draft added to documentation. | |
2488 | ||
2489 | Revision 1.12 2001/10/10 01:12:31 mcr | |
2490 | removed impact on DNS servers section. | |
2491 | removed nested comments. | |
2492 | adjusted data of issue | |
2493 | ||
2494 | Revision 1.11 2001/09/17 02:55:50 mcr | |
2495 | outline is now stable. | |
2496 | ||
2497 | Revision 1.5 2001/08/19 02:53:32 mcr | |
2498 | version 00d formatted. | |
2499 | ||
2500 | Revision 1.10 2001/08/19 02:34:04 mcr | |
2501 | version 00d formatted. | |
2502 | ||
2503 | Revision 1.9 2001/08/19 02:21:54 mcr | |
2504 | version 00d | |
2505 | ||
2506 | Revision 1.8 2001/07/20 19:07:06 mcr | |
2507 | commented out section 1.1 | |
2508 | ||
2509 | Revision 1.7 2001/07/20 14:14:22 mcr | |
2510 | HS and HD comments. | |
2511 | ||
2512 | Revision 1.6 2001/07/19 00:56:50 mcr | |
2513 | version 00b. | |
2514 | ||
2515 | Revision 1.5 2001/07/12 23:57:07 mcr | |
2516 | OE ID, 00. | |
2517 | ||
2518 | ||
2519 | !> |