doc/src/draft-richardson-ipsec-opportunistic.html

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