1 <html><head><title>A method for doing opportunistic encryption with IKE</title>
2 <STYLE type='text/css'>
3 .title { color: #990000; font-size: 22px; line-height: 22px; font-weight: bold; text-align: right;
4 font-family: helvetica, arial, sans-serif }
5 .filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right;
6 font-family: helvetica, arial, sans-serif }
7 p.copyright { color: #000000; font-size: 10px;
8 font-family: verdana, charcoal, helvetica, arial, sans-serif }
9 p { margin-left: 2em; margin-right: 2em; }
10 li { margin-left: 3em; }
11 ol { margin-left: 2em; margin-right: 2em; }
12 ul.text { margin-left: 2em; margin-right: 2em; }
13 pre { margin-left: 3em; color: #333333 }
14 ul.toc { color: #000000; line-height: 16px;
15 font-family: verdana, charcoal, helvetica, arial, sans-serif }
16 H3 { color: #333333; font-size: 16px; line-height: 16px; font-family: helvetica, arial, sans-serif }
17 H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, sans-serif }
18 TD.header { color: #ffffff; font-size: 10px; font-family: arial, helvetica, san-serif; valign: top }
19 TD.author-text { color: #000000; font-size: 10px;
20 font-family: verdana, charcoal, helvetica, arial, sans-serif }
21 TD.author { color: #000000; font-weight: bold; margin-left: 4em; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif }
22 A:link { color: #990000; font-size: 10px; text-transform: uppercase; font-weight: bold;
23 font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
24 A:visited { color: #333333; font-weight: bold; font-size: 10px; text-transform: uppercase;
25 font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
26 A:name { color: #333333; font-weight: bold; font-size: 10px; text-transform: uppercase;
27 font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
28 .link2 { color:#ffffff; font-weight: bold; text-decoration: none;
29 font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
31 .RFC { color:#666666; font-weight: bold; text-decoration: none;
32 font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
34 .hotText { color:#ffffff; font-weight: normal; text-decoration: none;
35 font-family: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
39 <body bgcolor="#ffffff" text="#000000" alink="#000000" vlink="#666666" link="#990000">
40 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
41 <table width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table width="100%" border="0" cellpadding="2" cellspacing="1">
42 <tr valign="top"><td width="33%" bgcolor="#666666" class="header">Network Working Group</td><td width="33%" bgcolor="#666666" class="header">M. Richardson</td></tr>
43 <tr valign="top"><td width="33%" bgcolor="#666666" class="header">Internet-Draft</td><td width="33%" bgcolor="#666666" class="header">SSW</td></tr>
44 <tr valign="top"><td width="33%" bgcolor="#666666" class="header">Expires: August 22, 2002</td><td width="33%" bgcolor="#666666" class="header">D. Redelmeier</td></tr>
45 <tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">Mimosa</td></tr>
46 <tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">H. Spencer</td></tr>
47 <tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">SP Systems</td></tr>
48 <tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">February 21, 2002</td></tr>
49 </table></td></tr></table>
50 <div align="right"><font face="monaco, MS Sans Serif" color="#990000" size="+3"><b><br><span class="title">A method for doing opportunistic encryption with IKE</span></b></font></div>
51 <div align="right"><font face="monaco, MS Sans Serif" color="#666666" size="+2"><b><span class="filename">draft-richardson-ipsec-opportunistic-06.txt</span></b></font></div>
52 <font face="verdana, helvetica, arial, sans-serif" size="2">
54 <h3>Status of this Memo</h3>
56 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.</p>
58 Internet-Drafts are working documents of the Internet Engineering
59 Task Force (IETF), its areas, and its working groups.
60 Note that other groups may also distribute working documents as
63 Internet-Drafts are draft documents valid for a maximum of six months
64 and may be updated, replaced, or obsoleted by other documents at any time.
65 It is inappropriate to use Internet-Drafts as reference material or to cite
66 them other than as "work in progress."</p>
68 The list of current Internet-Drafts can be accessed at
69 <a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
71 The list of Internet-Draft Shadow Directories can be accessed at
72 <a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
74 This Internet-Draft will expire on August 22, 2002.</p>
76 <h3>Copyright Notice</h3>
78 Copyright (C) The Internet Society (2002). All Rights Reserved.</p>
79 <a name="toc"><br><hr size="1" shade="0"></a>
80 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
81 <h3>Table of Contents</h3>
82 <ul compact class="toc">
83 <b><a href="#anchor1">1.</a>
85 <b><a href="#anchor2">1.1</a>
87 <b><a href="#anchor3">1.2</a>
88 Types of network traffic<br></b>
89 <b><a href="#anchor4">1.3</a>
90 Peer authentication in Opportunistic Encryption<br></b>
91 <b><a href="#anchor5">1.4</a>
92 Use of RFC2119 terms<br></b>
93 <b><a href="#anchor6">2.</a>
95 <b><a href="#anchor7">2.1</a>
96 Reference diagram<br></b>
97 <b><a href="#anchor8">2.2</a>
99 <b><a href="#anchor9">2.3</a>
100 Model of Operation<br></b>
101 <b><a href="#anchor10">2.3.1</a>
102 Tunnel Authorization<br></b>
103 <b><a href="#anchor11">2.3.2</a>
104 Tunnel End-point discovery<br></b>
105 <b><a href="#anchor12">2.3.3</a>
106 Caching of authorization results<br></b>
107 <b><a href="#anchor13">3.</a>
108 Specification<br></b>
109 <b><a href="#anchor14">3.1</a>
110 Datagram State Machine<br></b>
111 <b><a href="#anchor15">3.1.1</a>
112 Nonexistent policy<br></b>
113 <b><a href="#anchor16">3.1.2</a>
115 <b><a href="#anchor17">3.1.3</a>
116 Pass-through policy<br></b>
117 <b><a href="#anchor18">3.1.4</a>
119 <b><a href="#anchor19">3.1.5</a>
120 Encrypt policy<br></b>
121 <b><a href="#initclasses">3.2</a>
122 Keying State Machine - Initiator<br></b>
123 <b><a href="#anchor20">3.2.1</a>
124 Nonexistent connection<br></b>
125 <b><a href="#anchor21">3.2.2</a>
126 clear-text connection<br></b>
127 <b><a href="#anchor22">3.2.3</a>
128 Deny connection<br></b>
129 <b><a href="#anchor23">3.2.4</a>
130 Potential OE connection<br></b>
131 <b><a href="#nodnssec">3.2.4.1</a>
132 Restriction on unauthentication TXT delegation records<br></b>
133 <b><a href="#anchor24">3.2.5</a>
134 Pending OE connection<br></b>
135 <b><a href="#keyed">3.2.6</a>
136 Keyed connection<br></b>
137 <b><a href="#expiring">3.2.7</a>
138 Expiring connection<br></b>
139 <b><a href="#anchor25">3.2.8</a>
140 Expired connection state<br></b>
141 <b><a href="#anchor26">3.3</a>
142 Keying State Machine - Responder<br></b>
143 <b><a href="#anchor27">3.3.1</a>
144 Unauthenticated OE peer state<br></b>
145 <b><a href="#anchor28">3.3.2</a>
146 Authenticated OE Peer<br></b>
147 <b><a href="#teardown">3.4</a>
148 Renewal and Teardown<br></b>
149 <b><a href="#anchor29">3.4.1</a>
151 <b><a href="#anchor30">3.4.2</a>
152 Teardown and Cleanup<br></b>
153 <b><a href="#anchor31">4.</a>
154 Impacts on IKE<br></b>
155 <b><a href="#anchor32">4.1</a>
156 ISAKMP/IKE protocol<br></b>
157 <b><a href="#anchor33">4.2</a>
158 Gateway discovery process<br></b>
159 <b><a href="#anchor34">4.3</a>
160 Self identification<br></b>
161 <b><a href="#anchor35">4.4</a>
162 Public key Retrieval process<br></b>
163 <b><a href="#anchor36">4.5</a>
164 Interactions with DNSSEC<br></b>
165 <b><a href="#anchor37">4.6</a>
166 Recommended proposal types<br></b>
167 <b><a href="#phase1id">4.6.1</a>
168 Phase 1 parameters<br></b>
169 <b><a href="#phase2id">4.6.2</a>
170 Phase 2 parameters<br></b>
171 <b><a href="#anchor38">5.</a>
173 <b><a href="#KEY">5.1</a>
174 Use of KEY record<br></b>
175 <b><a href="#TXT">5.2</a>
176 Use of TXT delegation record<br></b>
177 <b><a href="#anchor39">5.2.1</a>
178 Choice of TXT record<br></b>
179 <b><a href="#fqdn">5.3</a>
180 Use of FQDN IDs<br></b>
181 <b><a href="#anchor40">6.</a>
182 Network Address Translation interaction<br></b>
183 <b><a href="#anchor41">6.1</a>
184 Colocated NAT/NAPT<br></b>
185 <b><a href="#anchor42">6.2</a>
186 SG-A behind NAT/NAPT<br></b>
187 <b><a href="#anchor43">6.3</a>
188 Bob is behind a NAT/NAPT<br></b>
189 <b><a href="#anchor44">7.</a>
190 Host implementations<br></b>
191 <b><a href="#anchor45">8.</a>
193 <b><a href="#anchor46">9.</a>
194 Failure modes<br></b>
195 <b><a href="#anchor47">9.1</a>
197 <b><a href="#anchor48">9.2</a>
198 DNS configured, IKE failures<br></b>
199 <b><a href="#anchor49">9.3</a>
200 System reboots<br></b>
201 <b><a href="#anchor50">10.</a>
202 Unresolved issues<br></b>
203 <b><a href="#anchor51">10.1</a>
204 Control of reverse DNS<br></b>
205 <b><a href="#anchor52">11.</a>
207 <b><a href="#anchor53">11.1</a>
208 Clear-text usage (permit policy)<br></b>
209 <b><a href="#anchor54">11.2</a>
210 Opportunistic Encryption<br></b>
211 <b><a href="#anchor55">11.2.1</a>
212 (5) IPsec packet interception<br></b>
213 <b><a href="#anchor56">11.2.2</a>
214 (5B) DNS lookup for TXT record<br></b>
215 <b><a href="#anchor57">11.2.3</a>
216 (5C) DNS returns TXT record(s)<br></b>
217 <b><a href="#anchor58">11.2.4</a>
218 (5D) Initial IKE Main Mode Packet goes out<br></b>
219 <b><a href="#anchor59">11.2.5</a>
220 (5E1) Message 2 of phase 1 exchange<br></b>
221 <b><a href="#anchor60">11.2.6</a>
222 (5E2) Message 3 of phase 1 exchange<br></b>
223 <b><a href="#anchor61">11.2.7</a>
224 (5E3) Message 4 of phase 1 exchange<br></b>
225 <b><a href="#anchor62">11.2.8</a>
226 (5E4) Message 5 of phase 1 exchange<br></b>
227 <b><a href="#anchor63">11.2.9</a>
228 (5F1) Responder lookup of initiator key<br></b>
229 <b><a href="#anchor64">11.2.10</a>
230 (5F2) DNS replies with public key of initiator<br></b>
231 <b><a href="#anchor65">11.2.11</a>
232 (5E5) Responder replies with ID and authentication<br></b>
233 <b><a href="#anchor66">11.2.12</a>
234 (5G) IKE phase 2<br></b>
235 <b><a href="#anchor67">11.2.12.1</a>
236 (5G1) Initiator proposes tunnel<br></b>
237 <b><a href="#anchor68">11.2.12.2</a>
238 (5H1) Responder determines initiator's authority<br></b>
239 <b><a href="#anchor69">11.2.12.3</a>
240 (5H2) DNS replies with TXT record<br></b>
241 <b><a href="#anchor70">11.2.12.4</a>
242 (5G2) Responder agrees to proposal<br></b>
243 <b><a href="#anchor71">11.2.12.5</a>
244 (5G3) Final acknowledgement from initiator<br></b>
245 <b><a href="#anchor72">11.2.13</a>
246 (6) IPsec succeeds, sets up tunnel for communication between Alice and Bob<br></b>
247 <b><a href="#anchor73">11.2.14</a>
248 (9) SG-B already has tunnel up with G1, uses it<br></b>
249 <b><a href="#securityconsiderations">12.</a>
250 Security Considerations<br></b>
251 <b><a href="#anchor74">12.1</a>
252 Configured vs Opportunistic Tunnels<br></b>
253 <b><a href="#anchor75">12.2</a>
254 Firewalls vs Opportunistic Tunnels<br></b>
255 <b><a href="#anchor76">12.3</a>
256 Denial of Service<br></b>
257 <b><a href="#anchor77">13.</a>
258 IANA Considerations<br></b>
259 <b><a href="#anchor78">14.</a>
260 Acknowledgements<br></b>
261 <b><a href="#rfc.references1">§</a>
263 <b><a href="#rfc.authors">§</a>
264 Authors' Addresses<br></b>
265 <b><a href="#rfc.copyright">§</a>
266 Full Copyright Statement<br></b>
274 This document describes opportunistic encryption using IKE and IPsec.
275 The objective is to allow encryption without any pre-arrangement
276 specific to the pair of gateways involved. Each gateway administrator
277 makes local arrangements to support opportunistic encryption. Once
278 that is done, any two such gateways can communicate securely.
284 There are two large payoffs. First, if many machines must communicate
285 securely, this approach reduces administrative overhead to order N
286 (number of gateways), rather than the N squared cost to configure each
287 tunnel separately. Second, it becomes possible to make secure
288 communication the default, even when the partner is not known in
295 There are naturally some risks and some costs, which are described.
301 This document is offered up as an Informational RFC.
305 <a name="anchor1"><br><hr size="1" shade="0"></a>
306 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
307 <h3>1. Introduction</h3>
309 <h4><a name="anchor2">1.1</a> Motivation</h4>
313 The objective of opportunistic encryption is to allow encryption without
314 any pre-arrangement specific to the pair of gateways involved. Each
315 gateway administrator makes local arrangements -- specifically, adds
316 public key information to DNS records -- to support opportunistic
317 encryption and then enables this feature in the nodes' IPsec stack.
318 Once that is done, any two such nodes can communicate securely.
324 This document describes opportunistic encryption as designed and
325 (to date, partially) implemented by the Linux FreeS/WAN project.
326 For project information, see www.freeswan.org.
332 The Internet Architecture Board (IAB) and Internet Engineering Steering Group
333 have taken a strong stand that the Internet should use powerful
334 encryption to provide security and privacy <a href="#RFC1984">[4]</a>. This project attempts to put
335 this policy into practice by providing practical means to implement them.
341 The project believes that the IPsec protocols are the best chance to
342 do that, because they are standardized, widely available and can often
343 be deployed very easily, without changing hardware or software or
344 retraining of users. However, the extension to opportunistic encryption
345 seems necessary, both to help control administrative overheads and
346 to get IPsec more widely used.
352 The use of "opportunistic encryption" offers the "fax effect". As each person
353 installs one for their own use, it becomes more valuable for their neighbors
354 to install one too, because there's one more person to use it with. The
355 software automatically notices each newly installed box, and doesn't
356 require a network administrator to reconfigure it.
362 This document describes the infrastructure needed to support this effort.
368 The term S/WAN is a trademark of RSA Data Systems, and is used with permission
373 <h4><a name="anchor3">1.2</a> Types of network traffic</h4>
377 To aid in understand the relationship between security processing and IPsec
378 we divide network traffic into four categories:
380 <blockquote class="text"><dl>
384 networks to which traffic is always forbidden
389 networks to which traffic in the clear is desired
392 <dt>opportunistic tunnel</dt>
394 networks to which encryption should be
395 done if possible, but communication is done in the clear otherwise
398 <dt>configured tunnel</dt>
400 networks to which encryption must be
401 done, and communication is never in the clear
411 This document describes the third category.
412 The first two categories are provided by traditional firewall devices.
413 The fourth category is presently the offering of many Virtual Private
414 Network (VPN) devices.
420 Category one, denied traffic by IP address, requires no authentication.
426 Category two, permitted traffic by IP address, requires no
427 authentication. This is the normal default on the Internet.
433 Category four, encrypt traffic or drop it, requires authentication of the
434 end points. As the number of end points is typically bounded and is typically
435 under the a single authority, arranging for distribution of
436 authentication material, while difficult, does not require any new
443 The mechanism described here provides an additional way to
444 distribute the authentication materials, notably a public key method that does not
445 require deployment of an X.509 based infrastructure.
449 <h4><a name="anchor4">1.3</a> Peer authentication in Opportunistic Encryption</h4>
453 Opportunistic encryption involves creating tunnels with other nodes that
454 are essentially strangers. This is done without any prior bilateral
456 There is therefore the difficult question of how does one know who one is
463 One possible answer is that one does not know who one is talking to. No useful
464 authentication can be done, so do not even try. This mode of operation has
465 been given the name "anonymous encryption". A man-in-the-middle attack can be
466 used to thwart the privacy of this communication. This would be an active attack.
467 Without peer authentication, there is no way to prevents this kind of attack.
473 Although a useful mode, it is not the goal of this project. It is a useful
474 starting point, but the system should permit additional layers of trust to
475 be built upon this system. In the described system, the anonymous
476 encryption case is what results without DNSSEC. Were anonymous encryption
477 the end goal, simpler methods are available to achieve this goal.
483 However, an essential premise of building private connections with
484 strangers is that datagrams received through these opportunistic tunnels
485 are no more special than datagrams that arrived in the clear.
491 Unlike in a VPN scenario, these datagrams should not be given any special
492 exceptions when it comes to auditing, further authentication or
499 On the outbound side, when initiating opportunistic encryption, it becomes
500 a local matter what to do if one fails to setup a tunnel. It may be that
501 the packet goes out in the clear, or it may be dropped. This is a local
502 configuration matter.
508 In sum, we gain wider privacy (for the Internet at large) at minimal cost:
509 the cost is the need to reassess assumptions about the relationship between
510 IPsec authentication and further local access control.
514 <h4><a name="anchor5">1.4</a> Use of RFC2119 terms</h4>
518 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
519 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
520 document, are to be interpreted as described in <a href="#RFC2119">[5]</a>
523 <a name="anchor6"><br><hr size="1" shade="0"></a>
524 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
525 <h3>2. Overview</h3>
527 <h4><a name="anchor7">2.1</a> Reference diagram</h4>
528 <br><hr size="1" shade="0">
529 <a name="networkdiagram"></a>
532 The following network diagram is used in the rest of
533 this document as the canonical diagram
538 [A]----+----[SG-A]...+....+....[SG-B]-------[B]
540 [D]----+----[SG-D]...+ +....[C] AS3
543 </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
548 <table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Reference Network Diagram </b></font><br></td></tr></table><hr size="1" shade="0">
552 In this diagram, there are four end-nodes: A, B, C and D.
553 There are three gateways, SG-A, SG-B, SG-D. A, D, SG-A and SG-D are part
554 of the same administrative authority. SG-A and SG-D are on two different exit
555 paths from organization 1. SG-B/B is an independent organizations.
556 Nodes Q and R are nodes that are on the Internet. PI is the Public
557 Internet ("The Wild").
561 <h4><a name="anchor8">2.2</a> Terminology</h4>
565 The following terminology is used in this document:
569 <blockquote class="text"><dl>
571 <dt>security gateway:</dt>
573 a system that performs IPsec tunnel
574 mode encapsulation/decapsulation. [SGx] in the diagram
579 node [A] in the diagram. When an IP address is needed, this is 192.1.0.65.
584 node [B] in the diagram. When an IP address is needed, this is 192.2.0.66.
589 node [C] in the diagram. When an IP address is needed, this is 192.1.1.67.
594 node [D] in the diagram. When an IP address is needed, this is 192.3.0.68
599 Alice's security gateway. Internally it is 192.1.0.1, externally it is 192.1.1.4.
604 Bob's security gateway. Internally it is 192.2.0.1, externally it is 192.1.1.5.
609 Dave's security gateway. Also Alice's backup security gateway. Internally it is 192.3.0.1, externally it is 192.1.1.6.
614 a single dash represents clear-text datagrams
619 an equals sign represents phase 2 (IPsec) cipher-text
625 a hash sign represents phase 1 (IKE) cipher-text
631 a period represents an untrusted network of unknown
635 <dt>configured tunnel:</dt>
637 Contrast with opportunistic tunnel. A tunnel that
638 is directly/deliberately/hand configured on participating gateways.
639 Configured tunnel are typically given a higher level of
640 trust than opportunistic tunnels.
643 <dt>road warrior tunnel:</dt>
645 a configured tunnel connecting one
646 node with a fixed IP address and one node with a variable IP address.
647 A road warrior (RW) connection must be initiated by the
648 variable node, since the fixed node does not know what the
649 address for the "road warrior" currently is.
652 <dt>anonymous encryption:</dt>
655 The process of encrypting a session without any knowledge of who the
656 other parities are. That is, no authentication of identities is done.
659 <dt>opportunistic encryption:</dt>
662 The process of encrypting a session with authenticated knowledge of
663 who the other parties are.
669 The negotiated period in seconds (bytes or datagrams) which a security
670 association will remain alive before needing to be re-keyed.
676 The effective time which a security association remains useful. A
677 security association with a lifespan shorter than its lifetime would
678 be removed when no longer needed. A security association with a
679 lifespan longer than its lifetime would need to be re-keyed one or
685 an ISAKMP/IKE security association, sometimes
686 also referred to as a keying channel.
691 an IPsec security association
696 another term for a set of phase 2 SA (one in each direction)
701 Network Address Translation
702 (see <a href="#RFC2663">[20]</a>)
707 Network Address and Port Translation
708 (see <a href="#RFC2663">[20]</a>)
711 <dt>default-free zone</dt>
714 The set of routers that maintain a complete set of routes to
715 all currently reachable destinations. Having such a list, these routers
716 never make use of a default route. A datagram with a destination address
717 not matching any route will be dropped by such a router.
724 <h4><a name="anchor9">2.3</a> Model of Operation</h4>
728 The Opportunistic Encryption security gateway ("OE gateway") is a regular
729 gateway node as described in <a href="#RFC0791">[2]</a> section 2.4 and
730 <a href="#RFC1009">[3]</a> with additional capabilities described here and
731 in <a href="#RFC2401">[7]</a>.
732 The algorithm described here provides a way to determine, for each datagram,
733 whether or not to apply an encrypting tunnel transformation to the
734 datagram. Thus, two important things that must be determined are whether or
735 not to tunnel and, if so, to which destination.
741 The OE gateway must also be capable of responding to other OE gateways as a
746 <h4><a name="anchor10">2.3.1</a> Tunnel Authorization</h4>
750 The decision as to whether or not to create a tunnel is determined on a
751 per-destination address basis. Upon receiving a packet with a destination
752 address not recently seen, the OE gateway performs a lookup in DNS for an
753 authorization record (see <a href="#TXT">Use of TXT delegation record</a>). This record is located using
754 the IP address to perform a search in the in-addr.arpa (IPv4) or ip6.arpa
755 (IPv6) maps. The presence of an authorization record indicates the desire for
756 a tunnel to be formed.
760 <h4><a name="anchor11">2.3.2</a> Tunnel End-point discovery</h4>
764 The record further provides the address or name of the
765 end-point which should be used.
771 The record may also provide the public RSA key of the tunnel end point
772 itself. This is provided for efficiency only - if this is not present, then
773 the address or name provided is used to perform a second lookup to find a KEY
780 DNSSEC (<a href="#RFC2535">[16]</a>) SHOULD be used to provide origin and
781 integrity protection of the Resource Records involved. Section
782 <a href="#nodnssec">Restriction on unauthentication TXT delegation records</a> documents a restriction on the tunnel end point if DNSSEC
783 signatures are not available for the relevant records.
787 <h4><a name="anchor12">2.3.3</a> Caching of authorization results</h4>
791 The OE gateway MUST maintain a list of source/destination pairs for which
792 Opportunistic Encryption has been attempted for a period of time. Successful
793 discovery of a tunnel end point SHOULD result in creation of a new security
794 association bundle between the OE gateway and the discovered tunnel end
801 Failure to discover an appropriate authorization MUST result in creation of a
802 forwarding policy entry to either drop or transmit in the clear future
803 datagrams. This negative cache is necessary so as to avoid repeatedly looking
804 up the same information, a possibly lengthly process.
810 OE gateways MUST time out all cache entries (both positive and negative ones)
811 periodically. This is done both to remove entries which are no longer
812 necessary, and to permit changes in authorization policy to be discovered.
816 <a name="anchor13"><br><hr size="1" shade="0"></a>
817 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
818 <h3>3. Specification</h3>
822 The OE gateway is modeled to have a forwarding plane and a control
823 plane. They are connected by a control channel such as PF_KEY.
824 (See <a href="#RFC2367">[6]</a>)
825 The forwarding plane performs per-datagram operations. The control plane
827 daemon such as ISAKMP/IKE and performs all authorization, authentication and
828 key derivation functions.
832 <h4><a name="anchor14">3.1</a> Datagram State Machine</h4>
836 Let the OE gateway maintain a collection of objects -- a superset of the
837 Security Policy Database specific in <a href="#RFC2401">[7]</a>. For
838 each combination of source and destination address, one may find an SPD
839 object in one of six states. Prior to forwarding each datagram, the
840 source and destination addresses are used to pick an entry from the SPD.
841 The SPD then determines how, and if, the packet is forwarded.
844 <h4><a name="anchor15">3.1.1</a> Nonexistent policy</h4>
848 If there is no entry found, then this policy applies.
849 An entry is created with an initial state of "Hold policy". A request for
850 keying material is sent to the keying daemon. The datagram is not forwarded,
851 rather it is attached to the SPD entry as the "first" datagram and retained
852 for eventual transmission in a new state.
856 <h4><a name="anchor16">3.1.2</a> Hold policy</h4>
860 A request for keying has been previously made. If the interface to the keying
861 system is lossy (PF_KEY, for instance, can be) a mechanism to retransmit the
862 keying request, rate limited to less than 1 request per second SHOULD be
864 The datagram is not forward. The datagram is attached to the SPD entry as the
865 "last" datagram and retained for eventual transmission. If there was
866 previously a datagram so stored, then it is discarded.
872 The retention of the first attempts to avoid waiting for a TCP retransmit,
873 as the first datagram is probably a TCP SYN packet. The retention of the last
874 datagram as well applies to streaming protocols, where it is useful to know
875 how much data has been lost. These are recommendations.
879 <h4><a name="anchor17">3.1.3</a> Pass-through policy</h4>
883 The datagram is forwarded using the normal forwarding table. This state is
884 entered only via command from the keying daemon. Upon entering this state,
885 the "first" and "last" datagrams are forwarded.
889 <h4><a name="anchor18">3.1.4</a> Deny policy</h4>
893 The datagram is discarded. This state is entered only via command from the
894 keying daemon. Upon entering this state, the "first" and "last" datagrams are
895 discarded. It is a local matter if further datagrams cause ICMP messages
896 to be generated (i.e. ICMP Administratively denied).
900 <h4><a name="anchor19">3.1.5</a> Encrypt policy</h4>
904 The datagram is encrypted using the indicated Security Association Database
906 This state is entered only via command from the keying daemon. Upon entering
907 this state, the "first" and "last" datagrams are using the new encrypt policy.
913 If the associated SAD entry expires (due to byte, packet or time limits) then
914 the entry returns to the Hold policy, causing an expire message to
915 communicated to the keying daemon.
920 All states may be created directly by the keying daemon while acting as a
925 <h4><a name="initclasses">3.2</a> Keying State Machine - Initiator</h4>
929 Let the keying daemon maintain a collection of objects -- let them be
930 called "connections" (or "conn"s for short). There are two categories of
931 connection objects: classes and instances. A class connection represents an
932 abstract policy - what could be. An instance represents an actual connection,
933 what is in fact implemented at the time.
939 Let there be two further subtypes of connections: keying channels (aka Phase
940 1 SAs) and data channels (aka Phase 2 SAs). Each data channel object may have
941 a corresponding SPD and SAD entry maintained by the Datagram State Machine.
947 For the purposes of Opportunistic Encryption, there MUST at least be
948 connection classes known as "deny", "always-clear-text", "OE-permissive",
950 The later two connection classes defines a set of source and/or destination
951 addresses for which Opportunistic Encryption will be attempted. There are a
952 number of additional places where the administrator MAY set policy
953 options. An implementation MAY create additional connection classes so that
954 these policies may be enacted in a more fine grained fashion.
960 {should the additional classes be given names here? - ed.}
965 The simplest system may need only the "OE-permissive" connection, and would
966 list its own (single) IP address as the source address of this policy, and
967 the wild-card address 0.0.0.0/0 as the destination IPv4 address. That is, the
968 simplest policy is to try Opportunistic Encryption with all destinations.
974 The distinction between permissive and paranoid OE use will become clear
975 in the state transition differences. In general, a permissive OE will, on
976 failure, install a pass-through policy, while a paranoid OE will, on failure,
977 install a drop policy.
983 In this description of the keying machines state transitions, the states
984 associated with the keying system itself are omitted. This is done for two
985 reasons: they are best documented in the keying system
986 (<a href="#RFC2407">[8]</a>,
987 <a href="#RFC2408">[9]</a> and <a href="#RFC2409">[10]</a> for ISAKMP/IKE),
988 and the details are keying system specific. Opportunistic Encryption is not
989 dependent upon any specific keying protocol, but this document does provide
990 requirements for those using ISAKMP/IKE to assure inter-operability.
996 The state transitions that may be involved in communicating with the
997 forwarding plane are omitted. PF_KEY and similar protocols have their own
998 state of states required for message sends and completion notifications.
1004 Finally, the retransmits and recursive lookups that are normal for DNS are
1005 not included in this state machine.
1009 <h4><a name="anchor20">3.2.1</a> Nonexistent connection</h4>
1013 There is no connection for a given source/destination address pair.
1014 Upon receipt of a request for keying material for this particular
1015 source/destination pair, a search is made through the connection classes to
1016 determine the most appropriate policy. Upon determining an appropriate
1017 connection class, then an instance object is created of that type.
1018 Both of the OE types results in a Potential OE connection.
1023 Failure to find an appropriate connection class results in an
1024 administrator defined default.
1030 In each case, when an appropriate class is found for the new flow
1031 then an instance connection is made of the type which matched.
1035 <h4><a name="anchor21">3.2.2</a> clear-text connection</h4>
1039 A transition is made from the empty connection to this state when an
1040 instance of the always-clear-text class is instantiated, or when an OE-permissive
1041 connection fails. During the transition, a pass-through policy object is created in the
1042 forwarding plane for the appropriate flow.
1048 The only way to leave this state is due to a timeout; see expiry connection.
1052 <h4><a name="anchor22">3.2.3</a> Deny connection</h4>
1056 A transition is made from the empty connection to this state when an
1057 instance of the deny class is instantiated, or when an OE-paranoid connection fails.
1058 During the transition, a deny policy object is created in the forwarding plane
1059 for the appropriate flow.
1065 The only way to leave this state is due to a timeout; see expiry connection.
1069 <h4><a name="anchor23">3.2.4</a> Potential OE connection</h4>
1073 A transition is made from the empty connection to this state when an
1074 instance of either OE class is instantiated.
1075 During the transition to this state, a hold policy object is created in the
1076 forwarding plane for the appropriate flow.
1082 In addition, when transitioning into this state, DNS lookup(s) are done in
1083 the reverse map for a TXT delegation resource record. (see <a href="#TXT">Use of TXT delegation record</a>)
1084 The destination address of the flow is used as the lookup key.
1090 There are three ways to exit this state: due a timeout in the DNS lookup, and
1091 via positive or negative replies as to the existence of the TXT delegation
1098 If there is a resource record found, and it is properly formatted, and if
1099 DNSSEC is enabled - the signature has been vouches for (either through local
1100 confirmation or via trusted path to a recursive DNSSEC server), then there is
1101 a transition to the Pending OE connection state. (Note that if the public key
1102 is not presented in the TXT delegation record, then it must be looked up as
1103 well as a sub-state. The DNS lookups are not considered a success until all
1104 have completed successfully)
1110 If there is no resource record found, or DNS times out then it is to be
1111 considered that this is not an OE capable receiver. If this was an
1112 OE-paranoid instance, then there is a transition to the deny connection.
1113 If this was an OE-permissive instance, then there is a transition to the
1114 clear-text connection.
1120 If the resource record is found but is misformed, or if DNSSEC has been
1121 enabled and reports a failure to authenticate, then there should be a
1122 transition to the deny connection. This fact should be logged. If the
1123 administrator wishes to override this, then an always-clear class can be
1124 installed for this flow. An implementation MAY make this situation a new
1129 <h4><a name="nodnssec">3.2.4.1</a> Restriction on unauthentication TXT delegation records</h4>
1133 An implementation SHOULD also provide an additional administrative control
1134 on delegation records and DNSSEC. This control would apply to delegation
1135 records (the TXT records in the reverse map) that are not protected by
1137 Records of this type are only permitted to delegate to their own address as
1138 a gateway. When this option is enabled, an active attack on DNS will be
1139 unable to redirect packets to other than the original destination.
1143 <h4><a name="anchor24">3.2.5</a> Pending OE connection</h4>
1147 A transition is made from the Potential OE connection to this state when
1148 it has been determined that we have all the information from DNS we would need, and
1149 should make an attempt to do keying for this connection. Upon entering this
1150 state, an attempt to initiate keying to the gateway provided is started.
1156 One exits from this state either with a successfully created IPsec SA, or
1157 with a failure of some kind. Successful SA creation results in a transition
1158 to the Key connection state.
1164 There are three failures which are distinguished. They are clearly not the
1165 only possible failures from keying, but these are the ones that have caused
1172 Note that if there were multiple gateways available in the TXT delegation
1173 records, then a failure can only be declared after all have been
1174 tried. Further, creation of a phase 1 SA does not constitute success - a set
1175 of phase 2 SAs (a tunnel) is considered success.
1181 The first failure is when an ICMP port unreachable is consistently received
1182 without any other communication, or when there is silence from the remote
1183 end. This likely means that the gateway is either not alive, or that the
1184 keying daemon is not functional. For an OE-permissive connection, transition
1185 to the clear-text connection, but with a rather low lifespan. The gateway may
1186 be in the process of rebooting, etc. For an OE-pessimistic connection,
1187 transition to the deny connection, again with a low lifespan.
1193 How long is long enough to wait for the remote keying daemon to wake up is
1194 a matter of some debate. 5 minutes is usually long enough for the network to
1195 reconverge if there is a routing failure. Many systems can reboot in that
1196 time as well. However, 5 minutes is far too long for most users to wait to
1197 hear that they can not connect with OE. Implementations SHOULD make this a
1204 If a phase 1 SA is created, but there is either no response to the phase 2
1205 proposal, or a negative notify (the notify must be authenticated) is
1206 received, then the remote gateway is not prepared to do OE at this time. As
1207 before transition to clear-text/deny based upon connection class, but this
1208 time with a normal lifespan.
1214 The third type of failure is when there is signature failure authenticating
1215 the remote gateway. In this case, again transition to clear-text/deny based
1216 upon the connection class, but make the timeout depend upon the remaining
1217 time to live in the DNS. (Note that DNSSEC signed resource records have a different
1218 expiry time from non-signed records) One possibility is that there has been a
1219 key roll-over, but that DNS has not caught up.
1223 <h4><a name="keyed">3.2.6</a> Keyed connection</h4>
1227 A transition is made from the Pending OE connection to this state when
1228 session keying material (aka the phase 2 SA) has been formed. An Encrypt
1229 Policy is created in the forwarding plane for this flow.
1235 There are three ways to exit this state. The first is by receipt of an
1236 authenticated delete message (via the keying channel) from the peer. This is
1237 normal teardown, and results in a transition to Expired connection.
1243 The second way is by expiry of the forwarding plane keying material. This
1244 causes a re-key operation to be started with a transition back to Pending OE
1245 connection. In general, the soft expiry will occur with sufficient time left
1246 for the keys to continue to be used. Note that a re-key can fail, which may
1247 result in the connection failing to clear-text or deny as
1248 appropriate. Note that the forwarding plane policy does not change until the
1249 rekeying attempt has failed or succeeded.
1255 The third way is via respond to a negotiation from a remote gateway, via
1256 receipt of a indication from the forwarding plane of having received unknown
1257 SPI from the gateway, or an ICMP from the remote gateway indicating an
1258 unknown SPI. Each of these things should be considered a hint that the remote
1259 gateway has rebooted or restarted. Since these can easily be forged, care
1260 muyst be exercised. A cautious (rate-limited) attempt to re-key the
1261 connection should be done.
1265 <h4><a name="expiring">3.2.7</a> Expiring connection</h4>
1269 Each of the deny, clear-text, and keyed connections will periodically be
1270 placed into this sub-state. See <a href="#teardown">Renewal and Teardown</a> for more details
1271 of how often this occurs.
1272 The forwarding plane is queried for last use time of the appropriate
1273 policy. If the use time is relatively recent, then the state returns to the
1274 previous deny, clear-text or keyed connection state. If not, then it enters
1275 the expired connection state.
1281 The DNS query and answer that lead to the state in question is also
1282 examined. It may have become stale. (A negative, i.e. no such record answer
1283 is valid for the period of time given by the MINIMUM field in an attached SOA
1284 record. See <a href="#RFC1034">[13]</a> section 4.3.4)
1285 If it has become stale, then a new query is made. If a change
1286 in the results are seen, then a transition to a new state is made as
1287 described in Potential OE connection state.
1293 Note that both outgoing SPD and incoming SAD must be queried as some flows
1294 may be unidirectional for some time.
1300 Note that the policy at the forwarding plane is not updated unless there
1301 is a conclusion that there should be a change.
1305 <h4><a name="anchor25">3.2.8</a> Expired connection state</h4>
1309 Entry to this state is due to no datagrams being forwarded recently via the
1310 appropriate SPD and SAD objects. The objects in the forwarding plane are
1311 removed (logging any final byte and packet counts if appropriate) and the
1312 connection instance in the keying plane is deleted.
1318 An ISAKMP/IKE Delete is sent to clean up the phase 2 SAs as described in
1319 <a href="#teardown">Renewal and Teardown</a>.
1325 A difficult question has been whether or not to also delete the phase 1 SAs
1326 at this time. This is left as a local implementation issue. Implementations
1327 that do delete the phase 1 SAs MUST send authenticated Delete messages to
1328 indicate that they are doing so. There is some advantage to simply keeping
1329 the phase 1 SAs around until they expire - they may prove useful again in the
1334 <h4><a name="anchor26">3.3</a> Keying State Machine - Responder</h4>
1338 The responder has an identical set of objects as the initiator.
1344 The responder gets its first indication that something is happening when it
1345 receives an invitation to create a keying channel from an initiator.
1349 <h4><a name="anchor27">3.3.1</a> Unauthenticated OE peer state</h4>
1353 Upon entering this state, a DNS lookup is done for a KEY record for the
1355 This is done in the reverse map for a KEY record for the initiator if the
1356 initiator has offered an ID_IPV4_ADDR, and in the forward map if the
1357 initiator has offered an ID_FQDN type. (See <a href="#RFC2407">[8]</a> section
1364 This state is exited upon successful receipt of a KEY from DNS, and use of it
1365 to verify the signature of the initiator.
1371 Successful authentication of the peer results in a transition to
1372 Authenticated OE Peer.
1378 Note that this state generally occurs in the middle of the key negotiation
1379 protocol. It is really a form of pseudo-state.
1383 <h4><a name="anchor28">3.3.2</a> Authenticated OE Peer</h4>
1387 The peer will eventually propose one or more phase 2 SAs. The source and
1388 destination address in the proposal are used to initialize the still empty
1389 connection state using the connection class table.
1390 A search for an identical connection object MUST be made at this point.
1396 If an identical connection is found, then delete the old instance that had
1398 and transition this new object to the Pending OE connection state. This means
1399 that new ISAKMP connections with a given peer will always use the latest
1400 instance, which is the correct one if the peer has rebooted in the interim.
1406 If an identical connection is not found, then transition according to the
1407 rules given for the initiator.
1413 Note that if the initiator is in OE-paranoid mode and the responder is in
1414 either always-clear-text or deny, then no communication is possible according
1415 to policy. An implementation is permitted to create new types of policies,
1416 such as "accept OE, but do not initiate it". This is a local matter.
1420 <h4><a name="teardown">3.4</a> Renewal and Teardown</h4>
1422 <h4><a name="anchor29">3.4.1</a> Aging</h4>
1426 A potentially unlimited number of tunnels may exist. In practice, only a few
1428 are used during a period of time. Unused tunnels MUST therefore be
1429 torn down. Detecting when they are no longer in use is the subject of this section.
1435 There are two methods in which the tunnel may be removed: by expiring
1436 or with explicit deletion.
1442 Explicit deletion is done with an IKE Delete message. To do this requires
1443 that both ends maintain the key channel (phase 1 ISAKMP SA), as the deletes
1444 MUST be authenticated. An implementation which refuses to either maintain or
1445 recreate the keying channel SA will be unable to use this method.
1451 In the expiry method, the tunnel is simply allowed by the IKE daemon to
1452 expire normally, without attempting to re-key it.
1458 Regardless of which method is used, a method is required to determine if the
1459 tunnel is still in use. This is a local matter, but the following criteria
1460 are what is used by the FreeSWAN project. This criteria is currently
1461 implemented in the key management daemon, but could also be implemented at
1462 the SPD layer using an idle timer.
1465 <blockquote class="text"><dl>
1469 a short initial (soft) lifespan of 1 minute is set. This is
1470 done since many net flows in fact last only a few seconds.
1475 at the end of the lifespan, a check is made to see if the
1476 tunnel was used by traffic in either direction during the last half of
1477 this period. If so, assign a longer tentative lifespan, of
1478 20 minutes, after which, look again. If the tunnel is not in
1479 use then close the tunnel.
1487 These timeouts are implemented by the Expiring state in the key management
1488 system (see <a href="#expiring">Expiring connection</a>).
1489 The timer given above may in fact be present in the forwarding plane,
1490 but it must, in this case be resettable.
1496 The tentative lifespan is independent of re-keying; it is just the time when
1497 the tunnel's future is next considered.
1498 (The term lifespan is used here rather than lifetime for this reason.)
1499 This should happen reasonably frequently, unlike re-keying, which is
1500 costly and shouldn't be too
1506 A multi-step back-off algorithm is not considered worth the effort here.
1512 If the security gateway and the client host are one and the
1513 same (and not a Bump-in-the-Stack or Bump-in-the-Wire implementation), tunnel
1514 teardown decisions MAY pay attention to TCP connection status, as reported
1515 by the local TCP layer.
1516 A still-open TCP connection is almost a guarantee that more traffic is
1517 coming, while the demise of the only TCP connection through a tunnel is a
1518 strong hint that no more traffic will transit.
1522 <h4><a name="anchor30">3.4.2</a> Teardown and Cleanup</h4>
1526 Teardown should always be coordinated with the other end.
1527 This means interpreting and sending Delete notifications. There is some
1528 detailed state in the Expired Connection state of the key manager that
1529 relates to retransmits of the Delete notifications, but this is considered to
1530 be a keying system detail.
1536 On receiving a Delete for the outbound SAs of a tunnel (or some subset of
1537 them), tear down the inbound ones too, and notify the other end with a
1538 Delete. If a Delete is received for a tunnel which is no longer in
1539 existence, then two Delete messages have crossed paths. Ignore the Delete -
1540 the operation has already been done. Do not generate any messages in this
1547 Tunnels need to be considered as bidirectional entities, even though the
1548 low-level protocols don't think of them that way.
1554 When the deletion is initiated locally, rather than as a
1555 response to a received Delete, send a Delete for (all) the
1556 inbound SAs of a tunnel. If no responding Delete is
1557 received for the outbound SAs, try re-sending the original
1558 Delete. Three tries spaced 10s apart seems a reasonable
1559 level of effort. A failure for the other end to respond at this point
1560 likely indicates that no further communication will be possible in any case.
1561 (Likely, it was a mobile node and it is not present or powered on anymore)
1567 After re-keying, transmission should switch to using the new
1568 outgoing SAs (ISAKMP or IPsec) immediately, and the old leftover SAs
1569 should be cleared out promptly (and Deletes sent) rather
1570 than waiting for them to expire. This reduces clutter and
1571 minimizes confusion for the operator doing diagnostics.
1575 <a name="anchor31"><br><hr size="1" shade="0"></a>
1576 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
1577 <h3>4. Impacts on IKE</h3>
1579 <h4><a name="anchor32">4.1</a> ISAKMP/IKE protocol</h4>
1583 The IKE wire protocol needs no modifications. The major changes are
1584 implementation issues relating to how the proposals are interpreted, and from
1591 As Opportunistic Encryption is designed to be useful between peers without
1592 prior operator configuration, an IKE daemon must be prepared to negotiate
1593 phase 1 SAs with any node. This may require a large amount of resources to
1594 maintain cookie state, as well as large amounts of entropy to for nonces,
1601 The major changes to support Opportunistic Encryption are at the IKE daemon
1602 level. These changes relate to handling of key acquisition requests, lookup
1603 of public keys and TXT records, and interactions with firewalls and other
1604 security facilities that may be coresident on the same gateway.
1608 <h4><a name="anchor33">4.2</a> Gateway discovery process</h4>
1612 In a typical configured tunnel situation, the address of SG-B is provided
1613 via configuration. Furthermore, the mapping of SPD entry to gateway is
1614 typically a 1:1 mapping. When the 0.0.0.0/0 SPD entry technique is used, then
1615 the mapping to a gateway is determined by the reverse DNS records.
1621 The need to do a DNS lookup and wait for a reply will typically introduce a
1622 new state and a new event source (DNS replies) to IKE. Although a synchronous
1623 DNS request can be done for proof of concept, this will not scale very well.
1629 Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with
1630 protocol some steps.
1634 <h4><a name="anchor34">4.3</a> Self identification</h4>
1638 SG-A will have to establish its identity. This is done by use of an
1644 There are many situations where the administrator of SG-A may not be
1645 able to control the reverse DNS records for SG-A's public IP address.
1646 Typical situations include
1647 dialup connections and most residential-type broadband Internet access
1648 (ADSL, cable-modem). In these situations, a fully qualified domain
1649 name which is under the control of SG-A's administrator may be used
1650 when acting as an initiator only.
1651 The FQDN ID should be used in phase 1. See <a href="#fqdn">Use of FQDN IDs</a>
1652 for more details and restrictions.
1656 <h4><a name="anchor35">4.4</a> Public key Retrieval process</h4>
1660 Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID, or
1661 an FQDN ID, an IKE daemon will need to examine local caches and
1662 configuration files to determine if this is part of a configured tunnel.
1663 If none is found, then the implementation should attempt to retrieve
1664 a KEY record from the reverse DNS (in the case of an IPv4/IPv6 ID), or
1665 from the forward DNS in the case of FQDN ID.
1671 It is reasonable that if other non-local sources of policy are used
1672 (COPS, LDAP, ...) that they be consulted concurrently, but that some
1673 clear ordering of policy be provided. Note that due to variances in
1674 latency, one must wait for positive or negative replies from all sources
1675 of policy before making any decisions.
1679 <h4><a name="anchor36">4.5</a> Interactions with DNSSEC</h4>
1683 The present implementation does not use DNSSEC to explicitly verify
1684 the authenticity of zone information, or use the NXT records to provide
1685 authentication of the absence of a TXT or KEY record. These are
1686 important considerations for practical use.
1692 In practice the verification of the DNSSEC SIG and NXT records will
1693 typically be done by a trusted DNS server. This process may be
1694 co-located, or reachable via a trusted path.
1698 <h4><a name="anchor37">4.6</a> Recommended proposal types</h4>
1700 <h4><a name="phase1id">4.6.1</a> Phase 1 parameters</h4>
1704 Main mode MUST be used.
1710 The initiator MUST offer at least one proposal using some combination
1711 of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be
1713 <a href="#MODPGROUPS">[12]</a>
1718 The initiator MAY offer additional proposals, but the cipher MUST not
1719 be weaker than 3DES. The initiator SHOULD limit the number of proposals
1720 such that the IKE datagrams do not need to be fragmented.
1726 The responder MUST accept one of the proposals. If any configuration
1727 of the responder is required then the responder is not acting in an
1734 SG-A SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6), of the external
1735 interface of SG-A for phase 1. (There is an exception, see <a href="#fqdn">Use of FQDN IDs</a>) The authentication method MUST be RSA public key signatures.
1741 The RSA key for SG-A MUST be placed into a DNS KEY record in
1742 the reverse space of SG-A. (i.e. using in-addr.arpa.)
1746 <h4><a name="phase2id">4.6.2</a> Phase 2 parameters</h4>
1750 SG-A MUST propose a tunnel between Alice and Bob, using 3DES-CBC
1751 mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be specified.
1757 Tunnel mode MUST be used.
1763 Authorization for SG-A to act on Alice's behalf is determined by
1764 looking for a TXT record in the reverse map at Alice's address.
1770 Compression SHOULD NOT be mandatory. It may be offered as an option.
1774 <a name="anchor38"><br><hr size="1" shade="0"></a>
1775 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
1776 <h3>5. DNS issues</h3>
1778 <h4><a name="KEY">5.1</a> Use of KEY record</h4>
1782 In order to establish their own identity, SG-A and SG-B must publish
1783 their public keys in their reverse DNS. This is just done via
1784 DNSSEC's KEY record.
1785 See section 3 of <a href="#RFC2535">RFC 2535</a>[16].
1795 KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
1796 </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
1798 <blockquote class="text"><dl>
1802 The flag bits, indicating that this key is prohibited
1803 for use confidentiality (it authenticates the peer only, DH is used for
1804 confidentiality), and that this key is associated with the non-zone entity
1805 whose name is the RR owner name. No other flags are set.
1810 This indicates that this key is for use by IPsec
1815 An RSA key is present
1818 <dt>AQNJjkKlIk9...nYyUkKK8</dt>
1820 the public key of the host as described in <a href="#RFC2537">[17]</a>
1828 <h4><a name="TXT">5.2</a> Use of TXT delegation record</h4>
1832 A TXT record is published by Alice (Bob) to provide authorization
1833 for SG-A (SG-B) to act on its behalf. This record is located in the
1834 reverse DNS (in-addr.arpa) for Alice's IP address.
1835 The reverse DNS SHOULD be secured by DNSSEC, when it is
1836 deployed. DNSSEC is required to defend against active attacks.
1842 If Alice's address is P.Q.R.S, then she can authorize another node to
1843 act on her behalf by publishing records at:
1845 S.R.Q.P.in-addr.arpa
1846 </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
1852 The contents of the resource record are expected to be a string that
1853 follows the following syntax, as suggested in <a href="#RFC1464">[15]</a>.
1854 (Note that the reply to query may include other TXT resource records from
1855 other applications may also be returned.)
1857 <br><hr size="1" shade="0">
1858 <a name="txtformat"></a>
1860 X-IPsec-Server(P)=A.B.C.D KEY
1861 </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
1862 <table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Format of reverse delegation record </b></font><br></td></tr></table><hr size="1" shade="0">
1866 <blockquote class="text"><dl>
1870 the P specifies a precedence for this record. This is
1871 similar to MX record preferences. Lower numbers have stronger
1878 specifies the IP address of the Security Gateway
1879 for this client machine.
1885 is the encoded RSA Public key of the Security
1886 Gateway. This is provided here to avoid a second DNS lookup. If this
1887 field is absent, then a KEY resource record should be looked up in the
1888 reverse map of A.B.C.D.
1897 In the case where Alice is located at a public address behind a
1898 security gateway that has no fixed address (or no control over its
1899 reverse map), then Alice may delegate to a public key by domain name:
1901 <br><hr size="1" shade="0">
1902 <a name="txtfqdnformat"></a>
1904 X-IPsec-Server(P)=@FQDN KEY
1905 </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
1906 <table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Format of reverse delegation record (FQDN version </b></font><br></td></tr></table><hr size="1" shade="0">
1910 <blockquote class="text"><dl>
1920 specifies the FQDN that the Security Gateway
1921 will identify itself with. Only useful for initiator.
1927 is the encoded RSA Public key of the Security
1936 If there is more than one such TXT record with strongest (lowest
1937 numbered) precedence, one Security Gateway is picked arbitrarily from
1938 those specified in the strongest-preference records. All keys for
1939 that Security Gateway are made available as candidates
1940 for signature checking. This mechanism is required to permit roll-over
1941 of signature keys in a seamless fashion.
1945 <h4><a name="anchor39">5.2.1</a> Choice of TXT record</h4>
1949 It has been suggested to use the OPT, CERT, KEY or KX records instead of
1955 The KEY RR has a Protocol field which could be used to indicate use
1956 for a new protocol, and an Algorithm field which could be used to
1957 indicate different contents in the key data. However, the KEY record
1958 is not clearly intended for storing what are really authorizations,
1959 it is just for identities. Other uses have been discouraged.
1964 OPT resource records, as defined in <a href="#RFC2671">[14]</a> are not
1965 intended to be used for storage of information. They are not to be loaded,
1966 cached or forwarded. They are therefore inappropriate for use here.
1972 CERT records <a href="#RFC2538">[18]</a> can encode almost any set of
1973 information. A custom Type code would be used permitting any suitable
1974 encoding to be stored, not just X.509. The certificate RR, according to
1975 the RFC, are to be signed internally, which may add undesirable and unnecessary
1976 bulk. Larger DNS records may require TCP transfers instead of UDP ones.
1982 At the time of protocol design, the CERT RR was not widely deployed and
1983 could not be counted upon. Use of CERT records will be investigated,
1984 and may result in a future revision of this document.
1990 KX records are ideally suited for this use, but had not been deployed at
1991 the time of implementation.
1995 <h4><a name="fqdn">5.3</a> Use of FQDN IDs</h4>
1999 Unfortunately, not every administrator has control over the contents
2000 of the reverse-map. The only case where we can work around this is
2001 where the initiator (SG-A) has no suitable reverse map. In this case, the
2002 authorization record present in the reverse map of Alice may refer to a
2003 FQDN instead of an IP address.
2009 In this case, the client's TXT record gives the fully qualified domain
2010 name (FQDN) in place of its security gateway's IP address.
2011 The initiator should use the ID_FQDN ID-payload in phase 1.
2012 A forward lookup for a KEY record on the FQDN must yield the
2013 initiator's public key.
2019 This method can also be used when the external address of SG-A is
2026 If SG-A is acting on behalf of Alice, then Alice must still delegate
2027 authority for SG-A to do so in her reverse map. When Alice and SG-A
2028 are one and the same (i.e. Alice is acting as an end-node) then there
2029 is no need for this when initiating only. Alice must still delegate to
2030 herself if she wishes to others to initiator OE to her.
2031 See <a href="#txtfqdnformat">Format of reverse delegation record (FQDN version</a>
2034 <a name="anchor40"><br><hr size="1" shade="0"></a>
2035 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
2036 <h3>6. Network Address Translation interaction</h3>
2040 There are no fundamentally new issues for getting opportunistic encryption
2041 to work in the presence of network address translation. Rather there are
2042 just the regular IPsec issues with NAT traversal.
2048 There are several situations to consider for NAT:
2052 <h4><a name="anchor41">6.1</a> Colocated NAT/NAPT</h4>
2056 If SG-A is also performing Network Address Translation on
2057 behalf of Alice, then the packet should be translated prior to
2058 being subjected to opportunistic encryption. This is in contrast to
2059 typical configured tunnel which often exist to bridge islands of
2060 private network address space. SG-A will use the translated source
2061 address for phase 2, and so SG-B will look that address up to
2062 confirm SG-A's authorization.
2067 In the case of NAT (1:1), the address space into which the
2068 translation is done MUST be globally unique, and control over the
2069 reverse map is assumed to be a given.
2070 Placing of TXT records is possible.
2075 In the case of NAPT (m:1), the address will be SG-A. The ability to get
2076 KEY and TXT records in place will again depend upon whether or not
2077 there is administrative control over the reverse map. This is
2078 identical situations involving a single host acting on behalf of
2081 FQDN style can be used to get around a lack of a reverse map for
2086 <h4><a name="anchor42">6.2</a> SG-A behind NAT/NAPT</h4>
2090 If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec
2091 NAT traversal rules would apply. In addition to the transport problem
2092 which can be solved via proposals like <a href="#ESPUDP">[11]</a>, there
2093 is the issue of what phase 1 and phase 2 IDs to use. While FQDN could
2094 be used during phase 1 for SG-A. An appropriate ID for phase 2
2096 to determine that SG-A was in fact authorized to speak for Alice.
2102 This is only possible if Alice actually has a public IP. It is a
2104 unusual case where a public network exists behind SG-A,
2105 while SG-A itself is behind a NAPT. This may occur with mobile networks
2106 of various kinds that occasionally wind up behind a NAPT.
2110 <h4><a name="anchor43">6.3</a> Bob is behind a NAT/NAPT</h4>
2114 If Bob is behind a NAT (perhaps SG-B), then there is in fact no way for
2115 Alice to address a packet to Bob. Not only is opportunistic encryption
2116 impossible, but it is also impossible for Alice to initiate any
2117 communication to Bob. It may be possible for Bob to initiate in such
2122 <a name="anchor44"><br><hr size="1" shade="0"></a>
2123 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
2124 <h3>7. Host implementations</h3>
2128 When Alice and SG-A are components of the same system, then this is
2129 considered to be a host implementation. The scenario remains unchanged
2130 with respect to packet sequence.
2136 Components marked Alice are simply the upper layers (TCP, UDP, the
2137 application), and SG-A is the IP layer.
2143 Note that tunnel mode is still recommended.
2149 As Alice/SG-A are acting on behalf of themselves, no TXT based delegation
2150 record is necessary for Alice to initiate. She can rely on a FQDN in a
2152 To respond, Alice/SG-A will still need an entry in her reverse map.
2156 <a name="anchor45"><br><hr size="1" shade="0"></a>
2157 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
2158 <h3>8. Multihoming</h3>
2162 If there are multiple paths between Alice and Bob (such as illustrated in
2163 the diagram with SG-D) then additional DNS records are required to establish
2170 In the diagram in <a href="#networkdiagram">Reference Network Diagram</a>, Alice has two ways to
2171 exit her network: SG-A and SG-D. Previously SG-D has been ignored. Postulate
2172 that there are routers between Alice and her set of security gateways
2173 (denoted by the + signs and the marking of an autonomous system number for
2174 Alice's network). Datagrams may therefore travel to either SG-A or SG-D en
2181 As long as all network connections are in good order it does not matter how
2182 datagrams exit Alice's network. When they reach either security gateway, the
2183 security gateway will find the TXT delegation record in Bob's reverse map,
2184 and establish an SA with SG-B.
2190 SG-B has no problem establishing that either of SG-A or SG-D may speak for
2191 Alice, as Alice has published two equally weighted TXT delegation records:
2192 <br><hr size="1" shade="0">
2193 <a name="txtmultiexample"></a>
2195 X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
2196 X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
2197 </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
2198 <table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Multiple gateway delegation example </b></font><br></td></tr></table><hr size="1" shade="0">
2204 Alice's routers can now happily do any kind of load sharing that they might
2205 wish to do. SG-A and SG-D will both send datagrams addressed to Bob through
2206 their tunnel to SG-B.
2212 If Alice wishes to prefer one gateway over another, then Bob should, upon
2213 finding that he has connections to two gateways en route to Alice, prefer the
2214 most recently established one - the precedence values are only valid for an
2215 initiator. It may be that the other one has experienced a failure, which is
2216 why Alice has switch to her less favourable backup.
2222 If the precedences are the same, then SG-B has a more difficult time. It
2223 must decide which of the two tunnels to use. SG-B has no information about
2224 which link is less loaded, nor which security gateway has more cryptographic
2225 resources available. SG-B in fact has no knowledge of whether both gateways
2232 The Public Internet's default free zone may well know a good route to Alice,
2233 but the datagrams that SG-B creates must be addressed to either SG-A or SG-D;
2234 they can not be addressed to Alice directly.
2240 There are a number of choices which SG-B may make:
2245 It can ignore the problem and round robin among the tunnels it has. This
2246 will cause losses during times when one or the other security gateway is
2247 unreachable. If this worries Alice, she can change the weights in her
2248 TXT delegation records.
2252 It can always send to the gateway that it most recently received from.
2253 This assumes that routing and reachability is symmetrical.
2257 It can listen to BGP information from the Internet to decide which
2258 system is currently up. This is clearly a much more complicated thing
2259 to do, but if SG-B is already doing this because it is participating
2260 in the BGP peering system to announce Bob, the results data may already
2265 It can refuse to negotiate the second tunnel. (It is unclear whether or
2266 not this is even an option)
2270 It can silently replace the outgoing portion of the first tunnel with the
2271 second one, while still retaining the incoming portions of both. SG-B can
2272 thus be willing willing to accept datagrams from either SG-A or SG-D, but
2273 sending only to the gateway that most recently rekeyed with it.
2283 These are decisions left to local policy. Note that even if SG-B has perfect
2284 knowledge about reachability of SG-A and SG-D, Alice may not be reachable
2285 from one or other of these security gateways due to internal reachability
2292 FreeS/WAN implements option 5. Consideration to implementing a different in
2293 being given. The multihoming aspects of this OE, not well developed and may
2294 be a subject of a future document.
2298 <a name="anchor46"><br><hr size="1" shade="0"></a>
2299 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
2300 <h3>9. Failure modes</h3>
2302 <h4><a name="anchor47">9.1</a> DNS failures</h4>
2306 If a DNS server fails to respond, then it is a local policy decision
2307 whether or not to permit communication in the clear. This is emboddied in
2308 the connection classes in <a href="#initclasses">Keying State Machine - Initiator</a>. It should be
2309 clear that mounting a denial of service attack on the DNS server
2310 responsible for a particular network's reverse map is an easy thing to do.
2311 Such an attack may cause all communication with that network to go in
2312 the clear for a permissive policy, and for communication to fail completely
2313 if this is a paranoid policy. Please note that this is an active attack.
2319 At the same time, there are still a very large number of networks
2320 that do not have properly configured reverse maps. Further, the effect of
2321 the above denial of service attack, if the policy is not to communicate,
2322 is that the target network becomes isolated. This is why this decision MUST
2323 be a matter of local policy.
2327 <h4><a name="anchor48">9.2</a> DNS configured, IKE failures</h4>
2331 In this situation, DNS records claim that opportunistic encryption should
2332 occur, but the target gateway either does not respond on port 500, or
2333 refuses the proposal. This may be due to a crash/reboot, due to
2334 misconfiguration, or a firewall filtering port 500.
2340 The receipt of ICMP port,
2341 host or network unreachable messages should be taken as a sign that there
2342 is a potential problem, but MUST NOT cause communication to fail
2343 immediately. ICMP messages are easily forged by attackers. If such a
2344 forgery caused immediate failure, then an attacker could easily prevent any
2345 encryption from ever occuring, possibly preventing all communication.
2351 It is recommended that in these situations that a clear log be produced
2352 about the problem. A local policy should dictate if communication is then
2353 permitted in the clear at this point.
2357 <h4><a name="anchor49">9.3</a> System reboots</h4>
2361 Tunnels sometimes go down because the other end crashes, or
2362 disconnects, or has a network link break, and there is no
2363 notice of this in the general case. (Even in the event of a
2364 crash and successful reboot, other SGs don't hear about it
2365 unless the rebooted SG has specific reason to talk to them
2366 immediately.) Over-quick response to temporary network out-
2367 ages is undesirable... but note that a tunnel can be torn
2368 down and then re-established without any user-visible effect
2369 except a pause in traffic, whereas if one end does reboot,
2370 the other end can't get datagrams to it at all (except via
2371 IKE) until the situation is noticed. So a bias toward quick
2372 response is appropriate, even at the cost of occasional
2379 A mechanism for recover after reboot is not specified in this
2380 document as it is a topic of current research.
2386 A deliberate shutdown should include an attempt to notify all other SGs
2387 currently connected by phase 1 SAs, using Deletes, that communication is
2388 about to fail. (Again, these will be taken as teardowns; attempts by the
2389 other SGs to negotiate new tunnels as replacements should be ignored at
2390 this point.) And when possible, SGs should attempt to preserve
2391 information about currently-connected SGs in non-volatile storage, so
2392 that after a crash, an Initial-Contact can be sent to previous partners to
2393 indicate loss of all previously established connections.
2397 <a name="anchor50"><br><hr size="1" shade="0"></a>
2398 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
2399 <h3>10. Unresolved issues</h3>
2401 <h4><a name="anchor51">10.1</a> Control of reverse DNS</h4>
2405 The method of obtaining information is by reverse DNS lookup causes
2406 problems for people who can not control their reverse DNS
2407 bindings. This is an unresolved problem in this version, and is out
2412 <a name="anchor52"><br><hr size="1" shade="0"></a>
2413 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
2414 <h3>11. Examples</h3>
2416 <h4><a name="anchor53">11.1</a> Clear-text usage (permit policy)</h4>
2420 What follows are two example scenarios. The first is where Gate1 and Gate2
2421 have always-cleartext policies, and the second where they have some OE
2425 <br><hr size="1" shade="0">
2426 <a name="regulartiming"></a>
2428 Alice Gate1 DNS Gate2 Bob
2429 Alice Gate1 DNS Gate2 Bob
2431 ------(2)-------------->
2432 <-----(3)---------------
2434 ----------(6)------>
2437 <----------(9)------
2440 ----------(12)----->
2443 <-------------------
2445 </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
2446 <table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Timing of regular transaction </b></font><br></td></tr></table><hr size="1" shade="0">
2450 Alice wants to send a packet to Bob, say a ping packet.
2451 Without the presence of opportunistic encryptors, the following events occur:
2453 <blockquote class="text"><dl>
2457 Human or application 'clicks' with a name
2462 Application looks up name in DNS to get IP address
2467 Resolver returns A record to application
2472 Application starts a TCP session or UDP session, OS sends packet
2477 Packet is seen at first gateway from Alice (SG-A) (Gate1
2478 transitions through Empty connection to always-clear connection and
2479 instantiates a passthrough policy at the forwarding plane)
2484 Packet is seen at last gateway before Bob (SG-B)
2489 First packet from Alice is seen by Bob
2494 First return packet is sent by Bob
2499 Packet is seen at Bob's gateway (Gate2 transitions through
2500 an Empty connection to always-clear connection and instantites a passthrough
2501 policy at the forwarding plane)
2506 Packet is seen at Alice's gateway
2511 OS hands packet to application, Alice sends another packet
2516 a second packet traverses the Internet
2524 <h4><a name="anchor54">11.2</a> Opportunistic Encryption</h4>
2528 In the presence of properly configured opportunistic encryptors, the
2529 event list is extended.
2531 <br><hr size="1" shade="0">
2532 <a name="opportunistictiming"></a>
2534 Alice SG-A DNS SG-B Bob
2536 ------(2)-------------->
2537 <-----(3)---------------
2541 -------------(5D)--->
2542 <------------(5E1)---
2543 -------------(5E2)-->
2544 <------------(5E3)---
2545 #############(5E4)##>
2546 <############(5E5)###
2549 #############(5G1)##>
2552 <############(5G2)###
2553 #############(5G3)##>
2554 ============(6)====>
2557 <==========(9)======
2560 ==========(12)=====>
2563 <===================
2565 </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
2566 <table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Timing of Opportunistic Encryption transaction </b></font><br></td></tr></table><hr size="1" shade="0">
2568 <blockquote class="text"><dl>
2572 Human or application clicks with a name
2577 Application initiates DNS mapping.
2582 resolver returns A record to application
2587 Application starts a TCP session or UDP
2592 SG (host or SG) sees packet to target, buffers it.
2597 SG asks the DNS for TXT record
2602 DNS returns TXT record(s)
2607 Initial IKE Main Mode Packet goes out
2612 IKE ISAKMP phase 1 succeeds
2617 SG-B asks the DNS for TXT record to prove SG-A agent for Alice
2622 IKE phase 2 negotiation
2627 DNS looksup by responder (SG-B)
2632 buffered packet is sent by SG-A
2637 packet is received by SG-B, and decrypted, sent to Bob
2642 Bob replies, packet is seen by SG-B
2647 SG-B already has tunnel up with SG-A, uses it
2652 SG-A decrypts packet and give it to Alice
2657 Alice receives packet. Sends new packet to Bob
2662 SG-A gets second packet, sees that tunnel is up, uses it
2672 For the purposes of this section, we will describe on the changes that
2673 occur between <a href="#regulartiming">Timing of regular transaction</a> and
2674 <a href="#opportunistictiming">Timing of Opportunistic Encryption transaction</a>. This means time points 5, 6, 7, 9 and 10.
2678 <h4><a name="anchor55">11.2.1</a> (5) IPsec packet interception</h4>
2682 At point (5), Security Gateway 1 intercepts the packet due to the
2683 lack of a policy (the non-existant policy!) for this source/destination
2684 pair. A hold policy is created, and the packet is buffered. A request is
2685 sent to the keying daemon for keys.
2689 <h4><a name="anchor56">11.2.2</a> (5B) DNS lookup for TXT record</h4>
2693 SG-A's IKE daemon, having looked up the source/destination in the connection
2694 class list, creates a new Potential OE connection instance. The DNS
2695 queries are started.
2699 <h4><a name="anchor57">11.2.3</a> (5C) DNS returns TXT record(s)</h4>
2703 DNS returns properly formed TXT delegation records, and SG-A's IKE daemon
2704 transitions this instance from Potential OE connection to Pending OE
2711 For the example above, the returned record might contain:
2713 <br><hr size="1" shade="0">
2714 <a name="txtexample"></a>
2716 X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
2717 </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
2718 <table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Example of reverse delegation record </b></font><br></td></tr></table><hr size="1" shade="0">
2720 with SG-B's IP address and public key listed.
2724 <h4><a name="anchor58">11.2.4</a> (5D) Initial IKE Main Mode Packet goes out</h4>
2727 Upon entering Pending OE connection, SG-A sends the initial ISAKMP
2728 message, with proposals, see <a href="#phase1id">Phase 1 parameters</a>.
2732 <h4><a name="anchor59">11.2.5</a> (5E1) Message 2 of phase 1 exchange</h4>
2736 SG-B receives the message. A new connection instance is created in the
2737 Unauthenticated OE Peer state.
2741 <h4><a name="anchor60">11.2.6</a> (5E2) Message 3 of phase 1 exchange</h4>
2745 SG-A sends a Diffie-Hellman exponent. This is an internal state of the
2750 <h4><a name="anchor61">11.2.7</a> (5E3) Message 4 of phase 1 exchange</h4>
2754 SG-B responds with a Diffie-Hellman exponent. This is an internal state of the
2759 <h4><a name="anchor62">11.2.8</a> (5E4) Message 5 of phase 1 exchange</h4>
2763 SG-A uses the phase 1 SA to send its identity under encryption.
2764 The choice of identity is discussed in <a href="#phase1id">Phase 1 parameters</a>.
2765 This is an internal state of the keying protocol.
2769 <h4><a name="anchor63">11.2.9</a> (5F1) Responder lookup of initiator key</h4>
2773 Security Gateway 2 asks DNS for the public key of the initiator.
2774 This is done by asking for a KEY record by IP address in the reverse map.
2775 That is, a KEY resource record is queried for 4.1.1.192.in-addr.arpa
2776 (recall that SG-A's external address is 192.1.1.4)
2777 The resulting public key is used to authenticate the initiator. See <a href="#KEY">Use of KEY record</a> for further details.
2781 <h4><a name="anchor64">11.2.10</a> (5F2) DNS replies with public key of initiator</h4>
2785 Upon successfully authenticating the peer, the connection instance is
2786 transitioned to Authenticated OE peer on SG-2.
2792 The format of the TXT record that is returned is described in
2793 <a href="#TXT">Use of TXT delegation record</a>.
2797 <h4><a name="anchor65">11.2.11</a> (5E5) Responder replies with ID and authentication</h4>
2801 SG-B sends its ID along with authentication material. This is an internal
2802 state for the keying protocol.
2806 <h4><a name="anchor66">11.2.12</a> (5G) IKE phase 2</h4>
2808 <h4><a name="anchor67">11.2.12.1</a> (5G1) Initiator proposes tunnel</h4>
2812 Having established mutually agreeable authentications (via KEY) and
2813 authorizations (via TXT), SG-A proposes to create an IPsec tunnel for
2814 datagrams transiting from Alice to Bob. This tunnel is established for only
2815 the A/B combination, not for any subnets that may be behind SG-A and SG-B.
2819 <h4><a name="anchor68">11.2.12.2</a> (5H1) Responder determines initiator's authority</h4>
2823 While the identity of the SG-A has been established, its authority to
2824 speak for Alice has not yet been confirmed. This is done by doing a reverse
2825 lookup on A's address for a TXT record.
2830 Upon receiving this specific proposal, SG-2 transitions its instance
2831 into the Potential OE connection state. SG-2 may already have an
2832 instance, and the check is made as described above.
2835 <h4><a name="anchor69">11.2.12.3</a> (5H2) DNS replies with TXT record</h4>
2839 The returned key and IP address should match that of SG-A.
2843 <h4><a name="anchor70">11.2.12.4</a> (5G2) Responder agrees to proposal</h4>
2847 Should additional communication occur between, for instance, D and B via
2848 SG-A and SG-B, a new tunnel (phase 2 SA) would be established. The phase 1 SA
2854 SG-A, having successfully keyed the tunnel, now transitions from
2855 Pending OE connection to Keyed OE connection.
2860 The responder MUST setup inbound IPsec SAs before sending its reply.
2863 <h4><a name="anchor71">11.2.12.5</a> (5G3) Final acknowledgement from initiator</h4>
2867 The initiator agrees with the responder's choice and sets up the tunnel.
2868 The initiator sets up inbound and outbound IPsec SAs.
2874 The proper authorization returned with keys SG-2 to transition its instance
2875 to the Keyed OE connection.
2880 Upon receipt of this message, the responder may now setup the outbound
2884 <h4><a name="anchor72">11.2.13</a> (6) IPsec succeeds, sets up tunnel for communication between Alice and Bob</h4>
2888 The packet which was saved at step (5) is sent through the newly created
2889 tunnel to SG-B. Bob receives it at (7) and replies at (8).
2893 <h4><a name="anchor73">11.2.14</a> (9) SG-B already has tunnel up with G1, uses it</h4>
2897 At (9), SG-B has already established an SPD entry mapping Bob->Alice via a
2898 tunnel, so this tunnel is simply applied. The packet is encrypted to SG-A,
2899 decrypted by SG-A and passed to Alice at (10).
2903 <a name="securityconsiderations"><br><hr size="1" shade="0"></a>
2904 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
2905 <h3>12. Security Considerations</h3>
2907 <h4><a name="anchor74">12.1</a> Configured vs Opportunistic Tunnels</h4>
2911 Configured tunnels are those which are setup using bilateral mechanisms: exchanging
2912 public keys (raw RSA, DSA, PKIX), pre-shared secrets, or by referencing keys that
2913 are in known places (distinguished name from LDAP, DNS). These keys are then used to
2914 configure a specific tunnel.
2920 A pre-configured tunnel may be on all the time, or may be keyed only when needed.
2921 The end points of the tunnel are not necessarily static: many mobile
2922 applications ("road warrior") are considered to be configured tunnels.
2928 The primary consideration is that configured tunnels are assigned specific
2929 security properties. They may be trusted in different ways. This is usually
2930 related to exceptions to firewall rules, exceptions to NAT processing, and to
2931 bandwidth or other quality of service restrictions.
2937 Opportunistic tunnels are not inherently trusted in any strong way. They are
2938 created without prior arrangement. As the two parties are strangers, there
2939 MUST be no confusion of datagrams that arrive from opportunistic peers and
2940 those that arrive from configured tunnels. A security gateway MUST take care
2941 that an opportunistic peer can not impersonate a configured peer.
2947 Ingress filtering MUST be used to make sure that only packets authorized by
2948 negotiation (and the concomitant authentication and authorization) are
2949 accepted from a tunnel. This is to prevent one peer from impersonating another.
2955 An implementation suggestion is to logically treat opportunistically tunnel
2956 datagrams as if they arrive on a distinct logical interface from other
2957 configured tunnels. As the number of opportunistic tunnels that may be
2958 created automatically on a system is potentially very high, careful attention
2959 to scaling should be taken into account.
2965 As with any IKE negotiation, opportunistic encryption cannot be secure
2966 without authentication. Opportunistic encryption relies on DNS for its
2967 authentication information and therefore cannot be fully secure without
2968 a secure DNS. Without secure DNS, it can protect against passive
2969 eavesdropping, but not against active man-in-the-middle attacks.
2973 <h4><a name="anchor75">12.2</a> Firewalls vs Opportunistic Tunnels</h4>
2977 Typical usage of per-packet access control lists is to implement various
2978 kinds of security gateways. These are typically called "firewalls".
2984 Typical usage of virtual private network (VPN) within a firewall is to
2985 bypass all or part of the access controls between two networks. Additional
2986 trust (as outlined in the previous section) is given to datagrams that arrive
2993 Datagrams that arrive via opportunistically configured tunnels MUST not be
2994 trusted. Any security policy that would apply to a packet arriving in the
2995 clear SHOULD also be applied to datagrams arriving opportunistically.
2999 <h4><a name="anchor76">12.3</a> Denial of Service</h4>
3003 There are several different forms of denial of service which an implementor
3004 should concern themselves with. Most of these problems are shared with
3005 security gateways that have large numbers of mobile peers (road warriors).
3011 The design of ISAKMP/IKE, and its use of cookies, defend against many kinds
3012 of denial of service. There is an assumption that if the phase 1 (ISAKMP)
3013 SA is authenticated, that it was worthwhile creating. Opportunism changes
3014 this assumption. As the gateway will communicate with anyone, it is
3015 possible to form phase 1 SAs with any machine on the Internet.
3019 <a name="anchor77"><br><hr size="1" shade="0"></a>
3020 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
3021 <h3>13. IANA Considerations</h3>
3025 There are no known numbers which IANA will need to manage.
3029 <a name="anchor78"><br><hr size="1" shade="0"></a>
3030 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
3031 <h3>14. Acknowledgements</h3>
3035 Thanks to Tero Kivinen, Sandy Harris, Wes Hardarker, Robert Moskowitz,
3036 Jakob Schlyter, Bill Sommerfeld, John Gilmore and John Denker for their
3037 comments and constructive criticism.
3041 <a name="rfc.references1"><br><hr size="1" shade="0"></a>
3042 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
3044 <table width="99%" border="0">
3045 <tr><td class="author-text" valign="top"><b><a name="OEspec">[1]</a></b></td>
3046 <td class="author-text"><a href="mailto:hugh@mimosa.com">Redelmeier, D.</a> and <a href="mailto:henry@spsystems.net">H. Spencer</a>, "Opportunistic Encryption", paper http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/opportunism.spec, May 2001.</td></tr>
3047 <tr><td class="author-text" valign="top"><b><a name="RFC0791">[2]</a></b></td>
3048 <td class="author-text">Defense Advanced Research Projects Agency (DARPA), Information Processing Techniques Office and , "<a href="ftp://ftp.isi.edu/in-notes/rfc791.txt">Internet Protocol</a>", STD 5, RFC 791, September 1981.</td></tr>
3049 <tr><td class="author-text" valign="top"><b><a name="RFC1009">[3]</a></b></td>
3050 <td class="author-text"><a href="mailto:">Braden, R.</a> and <a href="mailto:">J. Postel</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1009.txt">Requirements for Internet gateways</a>", RFC 1009, June 1987.</td></tr>
3051 <tr><td class="author-text" valign="top"><b><a name="RFC1984">[4]</a></b></td>
3052 <td class="author-text">IAB, IESG, <a href="mailto:brian@dxcoms.cern.ch">Carpenter, B.</a> and <a href="mailto:fred@cisco.com">F. Baker</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1984.txt">IAB and IESG Statement on Cryptographic Technology and the Internet</a>", RFC 1984, August 1996.</td></tr>
3053 <tr><td class="author-text" valign="top"><b><a name="RFC2119">[5]</a></b></td>
3054 <td class="author-text"><a href="mailto:-">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, March 1997.</td></tr>
3055 <tr><td class="author-text" valign="top"><b><a name="RFC2367">[6]</a></b></td>
3056 <td class="author-text"><a href="mailto:danmcd@eng.sun.com">McDonald, D.</a>, <a href="mailto:cmetz@inner.net">Metz, C.</a> and <a href="mailto:phan@itd.nrl.navy.mil">B. Phan</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2367.txt">PF_KEY Key Management API, Version 2</a>", RFC 2367, July 1998.</td></tr>
3057 <tr><td class="author-text" valign="top"><b><a name="RFC2401">[7]</a></b></td>
3058 <td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">Security Architecture for the Internet Protocol</a>", RFC 2401, November 1998.</td></tr>
3059 <tr><td class="author-text" valign="top"><b><a name="RFC2407">[8]</a></b></td>
3060 <td class="author-text"><a href="mailto:ddp@network-alchemy.com">Piper, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2407.txt">The Internet IP Security Domain of Interpretation for ISAKMP</a>", RFC 2407, November 1998.</td></tr>
3061 <tr><td class="author-text" valign="top"><b><a name="RFC2408">[9]</a></b></td>
3062 <td class="author-text"><a href="mailto:wdm@tycho.ncsc.mil">Maughan, D.</a>, <a href="mailto:mss@tycho.ncsc.mil">Schneider, M.</a> and <a href="er@raba.com">M. Schertler</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2408.txt">Internet Security Association and Key Management Protocol (ISAKMP)</a>", RFC 2408, November 1998.</td></tr>
3063 <tr><td class="author-text" valign="top"><b><a name="RFC2409">[10]</a></b></td>
3064 <td class="author-text"><a href="mailto:dharkins@cisco.com">Harkins, D.</a> and <a href="mailto:carrel@ipsec.org">D. Carrel</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2409.txt">The Internet Key Exchange (IKE)</a>", RFC 2409, November 1998.</td></tr>
3065 <tr><td class="author-text" valign="top"><b><a name="ESPUDP">[11]</a></b></td>
3066 <td class="author-text"><a href="mailto:Ari.Huttunen@F-Secure.com">Huttunen, A.</a> and <a href="mailto:wdixon@microsoft.com">W. Dixon</a>, "UDP Encapsulation of IPsec Packets", ID internet-draft (draft-ietf-ipsec-udp-encaps-00), June 2001.</td></tr>
3067 <tr><td class="author-text" valign="top"><b><a name="MODPGROUPS">[12]</a></b></td>
3068 <td class="author-text"><a href="mailto:kivinen@ssh.fi">Kivinen, T.</a> and <a href="mailto:mrskojo@cc.helsinki.fi">M. Kojo</a>, "More MODP Diffie-Hellman groups for IKE", ID internet-draft (draft-ietf-ipsec-ike-modp-groups-03), November 2001.</td></tr>
3069 <tr><td class="author-text" valign="top"><b><a name="RFC1034">[13]</a></b></td>
3070 <td class="author-text">Mockapetris, P., "<a href="ftp://ftp.isi.edu/in-notes/rfc1034.txt">Domain names - concepts and facilities</a>", STD 13, RFC 1034, November 1987.</td></tr>
3071 <tr><td class="author-text" valign="top"><b><a name="RFC2671">[14]</a></b></td>
3072 <td class="author-text"><a href="mailto:vixie@isc.org">Vixie, P.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2671.txt">Extension Mechanisms for DNS (EDNS0)</a>", RFC 2671, August 1999.</td></tr>
3073 <tr><td class="author-text" valign="top"><b><a name="RFC1464">[15]</a></b></td>
3074 <td class="author-text"><a href="mailto:rosenbaum@lkg.dec.com">Rosenbaum, R.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1464.txt">Using the Domain Name System To Store Arbitrary String Attributes</a>", RFC 1464, May 1993.</td></tr>
3075 <tr><td class="author-text" valign="top"><b><a name="RFC2535">[16]</a></b></td>
3076 <td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2535.txt">Domain Name System Security Extensions</a>", RFC 2535, March 1999.</td></tr>
3077 <tr><td class="author-text" valign="top"><b><a name="RFC2537">[17]</a></b></td>
3078 <td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2537.txt">RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</a>", RFC 2537, March 1999.</td></tr>
3079 <tr><td class="author-text" valign="top"><b><a name="RFC2538">[18]</a></b></td>
3080 <td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a> and <a href="mailto:ogud@tislabs.com">O. Gudmundsson</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2538.txt">Storing Certificates in the Domain Name System (DNS)</a>", RFC 2538, March 1999.</td></tr>
3081 <tr><td class="author-text" valign="top"><b><a name="RFC2748">[19]</a></b></td>
3082 <td class="author-text"><a href="mailto:David.Durham@intel.com">Durham, D.</a>, <a href="mailto:jboyle@Level3.net">Boyle, J.</a>, <a href="mailto:ronc@cisco.com">Cohen, R.</a>, <a href="mailto:herzog@iphighway.com">Herzog, S.</a>, <a href="mailto:rajan@research.att.com">Rajan, R.</a> and <a href="mailto:asastry@cisco.com">A. Sastry</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2748.txt">The COPS (Common Open Policy Service) Protocol</a>", RFC 2748, January 2000.</td></tr>
3083 <tr><td class="author-text" valign="top"><b><a name="RFC2663">[20]</a></b></td>
3084 <td class="author-text"><a href="mailto:srisuresh@lucent.com">Srisuresh, P.</a> and <a href="mailto:holdrege@lucent.com">M. Holdrege</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2663.txt">IP Network Address Translator (NAT) Terminology and Considerations</a>", RFC 2663, August 1999.</td></tr>
3087 <a name="rfc.authors"><br><hr size="1" shade="0"></a>
3088 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
3089 <h3>Authors' Addresses</h3>
3090 <table width="99%" border="0" cellpadding="0" cellspacing="0">
3091 <tr><td class="author-text"> </td>
3092 <td class="author-text">Michael C. Richardson</td></tr>
3093 <tr><td class="author-text"> </td>
3094 <td class="author-text">Sandelman Software Works</td></tr>
3095 <tr><td class="author-text"> </td>
3096 <td class="author-text">470 Dawson Avenue</td></tr>
3097 <tr><td class="author-text"> </td>
3098 <td class="author-text">Ottawa, ON K1Z 5V7</td></tr>
3099 <tr><td class="author-text"> </td>
3100 <td class="author-text">CA</td></tr>
3101 <tr><td class="author" align="right">EMail: </td>
3102 <td class="author-text"><a href="mailto:mcr@sandelman.ottawa.on.ca">mcr@sandelman.ottawa.on.ca</a></td></tr>
3103 <tr><td class="author" align="right">URI: </td>
3104 <td class="author-text"><a href="http://www.sandelman.ottawa.on.ca/">http://www.sandelman.ottawa.on.ca/</a></td></tr>
3105 <tr cellpadding="3"><td> </td><td> </td></tr>
3106 <tr><td class="author-text"> </td>
3107 <td class="author-text">D. Hugh Redelmeier</td></tr>
3108 <tr><td class="author-text"> </td>
3109 <td class="author-text">Mimosa</td></tr>
3110 <tr><td class="author-text"> </td>
3111 <td class="author-text">Toronto, ON</td></tr>
3112 <tr><td class="author-text"> </td>
3113 <td class="author-text">CA</td></tr>
3114 <tr><td class="author" align="right">EMail: </td>
3115 <td class="author-text"><a href="mailto:hugh@mimosa.com">hugh@mimosa.com</a></td></tr>
3116 <tr cellpadding="3"><td> </td><td> </td></tr>
3117 <tr><td class="author-text"> </td>
3118 <td class="author-text">Henry Spencer</td></tr>
3119 <tr><td class="author-text"> </td>
3120 <td class="author-text">SP Systems</td></tr>
3121 <tr><td class="author-text"> </td>
3122 <td class="author-text">Box 280 Station A</td></tr>
3123 <tr><td class="author-text"> </td>
3124 <td class="author-text">Toronto, ON M5W 1B2</td></tr>
3125 <tr><td class="author-text"> </td>
3126 <td class="author-text">Canada</td></tr>
3127 <tr><td class="author" align="right">EMail: </td>
3128 <td class="author-text"><a href="mailto:henry@spsystems.net">henry@spsystems.net</a></td></tr>
3130 <a name="rfc.copyright"><br><hr size="1" shade="0"></a>
3131 <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
3132 <h3>Full Copyright Statement</h3>
3133 <p class='copyright'>
3134 Copyright (C) The Internet Society (2002). All Rights Reserved.</p>
3135 <p class='copyright'>
3136 This document and translations of it may be copied and furnished to
3137 others, and derivative works that comment on or otherwise explain it
3138 or assist in its implementation may be prepared, copied, published and
3139 distributed, in whole or in part, without restriction of any kind,
3140 provided that the above copyright notice and this paragraph are
3141 included on all such copies and derivative works. However, this
3142 document itself may not be modified in any way, such as by removing
3143 the copyright notice or references to the Internet Society or other
3144 Internet organizations, except as needed for the purpose of
3145 developing Internet standards in which case the procedures for
3146 copyrights defined in the Internet Standards process must be
3147 followed, or as required to translate it into languages other than
3149 <p class='copyright'>
3150 The limited permissions granted above are perpetual and will not be
3151 revoked by the Internet Society or its successors or assigns.</p>
3152 <p class='copyright'>
3153 This document and the information contained herein is provided on an
3154 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
3155 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
3156 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
3157 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
3158 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p>
3159 <h3>Acknowledgement</h3>
3160 <p class='copyright'>
3161 Funding for the RFC Editor function is currently provided by the
3162 Internet Society.</p>
3163 </font></body></html>
OSDN Git Service
