<pre>Network Working Group                                      M. Richardson
Request for Comments: 4322                                           SSW
Category: Informational                                  D.H. Redelmeier
                                                                  Mimosa
                                                           December 2005


     <span class="h1">Opportunistic Encryption using the Internet Key Exchange (IKE)</span>

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes opportunistic encryption (OE) as designed and
   implemented by the Linux FreeS/WAN project.  OE uses the Internet Key
   Exchange (IKE) and IPsec protocols.  The objective is to allow
   encryption for secure communication without any pre-arrangement
   specific to the pair of systems involved.  DNS is used to distribute
   the public keys of each system involved.  This is resistant to
   passive attacks.  The use of DNS Security (DNSSEC) secures this
   system against active attackers as well.

   As a result, the administrative overhead is reduced from the square
   of the number of systems to a linear dependence, and it becomes
   possible to make secure communication the default even when the
   partner is not known in advance.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
      <a href="#section-1.1">1.1</a>. Motivation .................................................<a href="#page-3">3</a>
      <a href="#section-1.2">1.2</a>. Encryption Regimes .........................................<a href="#page-4">4</a>
      <a href="#section-1.3">1.3</a>. Peer Authentication in Opportunistic Encryption ............<a href="#page-4">4</a>
      <a href="#section-1.4">1.4</a>. Use of <a href="./rfc2119">RFC 2119</a> Terms ......................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. Overview ........................................................<a href="#page-6">6</a>
      <a href="#section-2.1">2.1</a>. Reference Diagram ..........................................<a href="#page-6">6</a>
      <a href="#section-2.2">2.2</a>. Terminology ................................................<a href="#page-6">6</a>
      <a href="#section-2.3">2.3</a>. Model of Operation .........................................<a href="#page-8">8</a>





<span class="grey">Richardson &amp; Redelmeier      Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   <a href="#section-3">3</a>. Protocol Specification ..........................................<a href="#page-9">9</a>
      <a href="#section-3.1">3.1</a>. Forwarding Plane State Machine .............................<a href="#page-9">9</a>
      <a href="#section-3.2">3.2</a>. Keying Daemon -- Initiator ................................<a href="#page-12">12</a>
      <a href="#section-3.3">3.3</a>. Keying Daemon -- Responder ................................<a href="#page-20">20</a>
      <a href="#section-3.4">3.4</a>. Renewal and Teardown ......................................<a href="#page-22">22</a>
   <a href="#section-4">4</a>. Impacts on IKE .................................................<a href="#page-24">24</a>
      <a href="#section-4.1">4.1</a>. ISAKMP/IKE Protocol .......................................<a href="#page-24">24</a>
      <a href="#section-4.2">4.2</a>. Gateway Discovery Process .................................<a href="#page-24">24</a>
      <a href="#section-4.3">4.3</a>. Self Identification .......................................<a href="#page-24">24</a>
      <a href="#section-4.4">4.4</a>. Public Key Retrieval Process ..............................<a href="#page-25">25</a>
      <a href="#section-4.5">4.5</a>. Interactions with DNSSEC ..................................<a href="#page-25">25</a>
      <a href="#section-4.6">4.6</a>. Required Proposal Types ...................................<a href="#page-25">25</a>
   <a href="#section-5">5</a>. DNS Issues .....................................................<a href="#page-26">26</a>
      <a href="#section-5.1">5.1</a>. Use of KEY Record .........................................<a href="#page-26">26</a>
      <a href="#section-5.2">5.2</a>. Use of TXT Delegation Record ..............................<a href="#page-27">27</a>
      <a href="#section-5.3">5.3</a>. Use of FQDN IDs ...........................................<a href="#page-29">29</a>
      <a href="#section-5.4">5.4</a>. Key Roll-Over .............................................<a href="#page-29">29</a>
   <a href="#section-6">6</a>. Network Address Translation Interaction ........................<a href="#page-30">30</a>
      <a href="#section-6.1">6.1</a>. Co-Located NAT/NAPT .......................................<a href="#page-30">30</a>
      <a href="#section-6.2">6.2</a>. Security Gateway behind a NAT/NAPT ........................<a href="#page-30">30</a>
      <a href="#section-6.3">6.3</a>. End System behind a NAT/NAPT ..............................<a href="#page-31">31</a>
   <a href="#section-7">7</a>. Host Implementations ...........................................<a href="#page-31">31</a>
   <a href="#section-8">8</a>. Multi-Homing ...................................................<a href="#page-31">31</a>
   <a href="#section-9">9</a>. Failure Modes ..................................................<a href="#page-33">33</a>
      <a href="#section-9.1">9.1</a>. DNS Failures ..............................................<a href="#page-33">33</a>
      <a href="#section-9.2">9.2</a>. DNS Configured, IKE Failures ..............................<a href="#page-33">33</a>
      <a href="#section-9.3">9.3</a>. System Reboots ............................................<a href="#page-34">34</a>
   <a href="#section-10">10</a>. Unresolved Issues .............................................<a href="#page-34">34</a>
      <a href="#section-10.1">10.1</a>. Control of Reverse DNS ...................................<a href="#page-34">34</a>
   <a href="#section-11">11</a>. Examples ......................................................<a href="#page-34">34</a>
      <a href="#section-11.1">11.1</a>. Clear-Text Usage (Permit Policy) .........................<a href="#page-34">34</a>
      <a href="#section-11.2">11.2</a>. Opportunistic Encryption .................................<a href="#page-36">36</a>
   <a href="#section-12">12</a>. Security Considerations .......................................<a href="#page-39">39</a>
      <a href="#section-12.1">12.1</a>. Configured versus Opportunistic Tunnels ..................<a href="#page-39">39</a>
      <a href="#section-12.2">12.2</a>. Firewalls versus Opportunistic Tunnels ...................<a href="#page-40">40</a>
      <a href="#section-12.3">12.3</a>. Denial of Service ........................................<a href="#page-41">41</a>
   <a href="#section-13">13</a>. Acknowledgements ..............................................<a href="#page-41">41</a>
   <a href="#section-14">14</a>. References ....................................................<a href="#page-41">41</a>
      <a href="#section-14.1">14.1</a>. Normative References .....................................<a href="#page-41">41</a>
      <a href="#section-14.2">14.2</a>. Informative References ...................................<a href="#page-42">42</a>











<span class="grey">Richardson &amp; Redelmeier      Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Motivation</span>

   The objective of opportunistic encryption is to allow encryption
   without any pre-arrangement specific to the pair of systems involved.
   Each system administrator adds public key information to DNS records
   to support opportunistic encryption and then enables this feature in
   the nodes' IPsec stack.  Once this is done, any two such nodes can
   communicate securely.

   This document describes opportunistic encryption as designed and
   implemented by the Linux FreeS/WAN project in revisions up and
   including 2.00.  Note that 2.01 and beyond implements [<a href="./rfc3445" title="&quot;Limiting the Scope of the KEY Resource Record (RR)&quot;">RFC3445</a>] in a
   backward compatible way.  A future document [<a href="#ref-IPSECKEY" title="&quot;A Method for Storing IPsec keying Material in DNS&quot;">IPSECKEY</a>] will describe
   a variation that complies with <a href="./rfc3445">RFC 3445</a>.  For project information,
   see <a href="http://www.freeswan.org">http://www.freeswan.org</a>.

   The Internet Architecture Board (IAB) and Internet Engineering
   Steering Group (IESG) have taken a strong stand that the Internet
   should use powerful encryption to provide security and privacy
   [<a href="./rfc1984" title="&quot;IAB and IESG Statement on Cryptographic Technology and the Internet&quot;">RFC1984</a>].  The Linux FreeS/WAN project attempts to provide a
   practical means to implement this policy.

   The project uses the IPsec, ISAKMP/IKE, DNS, and DNSSEC protocols
   because they are standardized, widely available, and can often be
   deployed very easily without changing hardware or software, or
   retraining users.

   The extensions to support opportunistic encryption are simple.  No
   changes to any on-the-wire formats are needed.  The only changes are
   to the policy decision making system.  This means that opportunistic
   encryption can be implemented with very minimal changes to an
   existing IPsec implementation.

   Opportunistic encryption creates a "fax effect".  The proliferation
   of the fax machine was possible because it did not require that
   everyone buy one overnight.  Instead, as each person installed one,
   the value of having one increased because there were more people that
   could receive faxes.  Once opportunistic encryption is installed, it
   automatically recognizes other boxes using opportunistic encryption,
   without any further configuration by the network administrator.  So,
   as opportunistic encryption software is installed on more boxes, its
   value as a tool increases.

   This document describes the infrastructure to permit deployment of
   Opportunistic Encryption.




<span class="grey">Richardson &amp; Redelmeier      Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   The term S/WAN is a trademark of RSA Data Systems, and is used with
   permission by this project.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Encryption Regimes</span>

   To aid in understanding the relationship between security processing
   and IPsec, we divide policies controlling network traffic into four
   categories.  The traffic is categorized by destination address using
   longest prefix match.  Therefore, each category is enumerated by a
   set of network prefixes.  The categories are mutually exclusive; a
   particular prefix should only occur in one category.

   * Deny: network prefixes to which traffic is always forbidden.
   * Permit: network prefixes to which traffic in the clear is
     permitted.
   * Opportunistic tunnel: network prefixes to which traffic is
     encrypted if possible, when it otherwise might be sent in the
     clear.
   * Configured tunnel: network prefixes to which traffic must be
     encrypted, and traffic in the clear is never permitted.  A
     traditionally defined Virtual Private Network (VPN) is a form of
     configured tunnel.

   Traditional firewall devices handle the first two categories.  No
   authentication is required.  The permit policy is currently the
   default on the Internet.

   This document describes the third category: opportunistic tunnel,
   which is proposed as the new default for the Internet.

   Category four's policy is a very strict "encrypt it or drop it"
   policy, which requires authentication of the endpoints.  As the
   number of endpoints is typically bounded and is typically under a
   single authority, arranging for distribution of authentication
   material, while difficult, does not require any new technology.  The
   mechanism described here, however, does provides an additional way to
   distribute the authentication materials; it is a public key method
   that does not require deployment of an X.509 based infrastructure.

<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>.  Peer Authentication in Opportunistic Encryption</span>

   Opportunistic encryption creates tunnels between nodes that are
   essentially strangers.  This is done without any prior bilateral
   arrangement.  Therefore, there is the difficult question of how one
   knows to whom one is talking.






<span class="grey">Richardson &amp; Redelmeier      Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   One possible answer is that since no useful authentication can be
   done, none should be tried.  This mode of operation is named
   "anonymous encryption".  An active man-in-the-middle attack can be
   used to thwart the privacy of this type of communication.  Without
   peer authentication, there is no way to prevent this kind of attack.

   Although it is a useful mode, anonymous encryption is not the goal of
   this project.  Simpler methods are available that can achieve
   anonymous encryption only, but authentication of the peer is a
   desirable goal.  Authentication of the peer is achieved through key
   distribution in DNS, leveraging upon the authentication of the DNS in
   DNSSEC.

   Peers are, therefore, authenticated with DNSSEC when available.
   Local policy determines how much trust to extend when DNSSEC is not
   available.

   An essential premise of building private connections with strangers
   is that datagrams received through opportunistic tunnels are no more
   special than datagrams that arrive in the clear.  Unlike in a VPN,
   these datagrams should not be given any special exceptions when it
   comes to auditing, further authentication, or firewalling.

   When initiating outbound opportunistic encryption, local
   configuration determines what happens if tunnel setup fails.  The
   packet may go out in the clear, or it may be dropped.

<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>.  Use of <a href="./rfc2119">RFC 2119</a> Terms</span>

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>]



















<span class="grey">Richardson &amp; Redelmeier      Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Overview</span>

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Reference Diagram</span>

   The following network diagram is used in the rest of this document as
   the canonical diagram:

                              [<a id="ref-Q">Q</a>]  [R]
                               .    .              AS2
      [A]----+----[SG-A].......+....+.......[SG-B]-------[B]
             |                 ......
         AS1 |                 ..PI..
             |                 ......
      [D]----+----[SG-D].......+....+.......[C] AS3

                    Figure 1: Reference Network Diagram

   In this diagram, there are four end-nodes: A, B, C, and D.  There are
   three security gateways, SG-A, SG-B, SG-D.  A, D, SG-A, and SG-D are
   part of the same administrative authority, AS1.  SG-A and SG-D are on
   two different exit paths from organization 1.  SG-B and B are part of
   an independent organization, AS2.  Nodes Q and R are nodes on the
   Internet.  PI is the Public Internet ("The Wild").

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Terminology</span>

   Note: The network numbers used in this document are for illustrative
   purposes only.  This document could not use the reserved example
   network numbers of [<a href="./rfc3330" title="&quot;Special-Use IPv4 Addresses&quot;">RFC3330</a>] because multiple address ranges were
   needed.

   The following terminology is used in this document:

   Security gateway (or simply gateway): a system that performs IPsec
      tunnel mode encapsulation/decapsulation.  [SG-x] in the diagram.

   Alice: node [A] in the diagram.  When an IP address is needed, this
      is 192.1.0.65.

   Bob: node [B] in the diagram.  When an IP address is needed, this is
      192.2.0.66.

   Carol: node [C] in the diagram.  When an IP address is needed, this
      is 192.1.1.67.

   Dave: node [D] in the diagram.  When an IP address is needed, this is
      192.3.0.68.




<span class="grey">Richardson &amp; Redelmeier      Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   SG-A: Alice's security gateway.  Internally it is 192.1.0.1,
      externally it is 192.1.1.4.

   SG-B: Bob's security gateway.  Internally it is 192.2.0.1, externally
      it is 192.1.1.5.

   SG-D: Dave's security gateway.  Also Alice's backup security gateway.
      Internally it is 192.3.0.1, externally it is 192.1.1.6.

   Configured tunnel: a tunnel that is directly and deliberately hand-
      configured on participating gateways.  Configured tunnels are
      typically given a higher level of trust than opportunistic
      tunnels.

   Road warrior tunnel: a configured tunnel connecting one node with a
      fixed IP address and one node with a variable IP address.  A road
      warrior (RW) connection must be initiated by the variable node,
      since the fixed node cannot know the current address for the road
      warrior.

   Anonymous encryption: the process of encrypting a session without any
      knowledge of who the other parties are.  No authentication of
      identities is done.

   Opportunistic encryption: the process of encrypting a session with
      authenticated knowledge of who the other party is without
      prearrangement.

   Lifetime: the period in seconds (bytes or datagrams) for which a
      security association will remain alive before rekeying is needed.

   Lifespan: the effective time for which a security association remains
      useful.  A security association with a lifespan shorter than its
      lifetime would be removed when no longer needed.  A security
      association with a lifespan longer than its lifetime would need to
      be re-keyed one or more times.

   Phase 1 SA: an ISAKMP/IKE security association sometimes referred to
      as a keying channel.

   Phase 2 SA: an IPsec security association.

   Tunnel: another term for a set of phase 2 SA (one in each direction).

   NAT: Network Address Translation (see [<a href="./rfc2663" title="&quot;IP Network Address Translator (NAT) Terminology and Considerations&quot;">RFC2663</a>]).

   NAPT: Network Address and Port Translation (see [<a href="./rfc2663" title="&quot;IP Network Address Translator (NAT) Terminology and Considerations&quot;">RFC2663</a>]).




<span class="grey">Richardson &amp; Redelmeier      Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   AS: an autonomous system.

   FQDN: Fully-Qualified Domain Name

   Default-free zone: a set of routers that maintain a complete set of
      routes to all currently reachable destinations.  Having such a
      list, these routers never make use of a default route.  A datagram
      with a destination address not matching any route will be dropped
      by such a router.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Model of Operation</span>

   The opportunistic encryption security gateway (OE gateway) is a
   regular gateway node, as described in <a href="./rfc0791#section-2.4">[RFC0791] section&nbsp;2.4</a> and
   [<a href="./rfc1812" title="&quot;Requirements for IP Version 4 Routers&quot;">RFC1812</a>], with the additional capabilities described here and in
   [<a href="./rfc2401" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC2401</a>].  The algorithm described here provides a way to determine,
   for each datagram, whether or not to encrypt and tunnel the datagram.
   Two important things that must be determined are whether or not to
   encrypt and tunnel and, if so, the destination address or name of the
   tunnel endpoint that should be used.

<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>.  Tunnel Authorization</span>

   The OE gateway determines whether or not to create a tunnel based on
   the destination address of each packet.  Upon receiving a packet with
   a destination address not recently seen, the OE gateway performs a
   lookup in DNS for an authorization resource record (see <a href="#section-5.2">Section 5.2</a>).
   The record is located using the IP address to perform a search in the
   in-addr.arpa (IPv4) or ip6.arpa (IPv6) maps.  If an authorization
   record is found, the OE gateway interprets this as a request for a
   tunnel to be formed.

<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>.  Tunnel Endpoint Discovery</span>

   The authorization resource record also provides the address or name
   of the tunnel endpoint that should be used.

   The record may also provide the public RSA key of the tunnel end
   point itself.  This is provided for efficiency only.  If the public
   RSA key is not present, the OE gateway performs a second lookup to
   find a KEY resource record for the endpoint address or name.

   Origin and integrity protection of the resource records is provided
   by DNSSEC (see [<a href="./rfc4033" title="&quot;DNS Security Introduction and Requirements&quot;">RFC4033</a>]).  <a href="#section-3.2.4.1">Section 3.2.4.1</a> documents an optional
   restriction on the tunnel endpoint if DNSSEC signatures are not
   available for the relevant records.





<span class="grey">Richardson &amp; Redelmeier      Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


<span class="h4"><a class="selflink" id="section-2.3.3" href="#section-2.3.3">2.3.3</a>.  Caching of Authorization Results</span>

   The OE gateway maintains a cache, in the forwarding plane, of
   source/destination pairs for which opportunistic encryption has been
   attempted.  This cache maintains a record of whether or not OE was
   successful so that subsequent datagrams can be forwarded properly
   without additional delay.

   Successful negotiation of OE instantiates a new security association.
   Failure to negotiate OE results in creation of a forwarding policy
   entry either to deny or permit transmission in the clear future
   datagrams.  This negative cache is necessary to avoid the possibly
   lengthy process of repeatedly looking up the same information.

   The cache is timed out periodically, as described in <a href="#section-3.4">Section 3.4</a>.
   This removes entries that are no longer being used and permits the
   discovery of changes in authorization policy.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Protocol Specification</span>

   The OE gateway is modeled to have a forwarding plane and a control
   plane.  A control channel, such as PF_KEY [<a href="./rfc2367" title="&quot;PF_KEY Key Management API, Version 2&quot;">RFC2367</a>], connects the two
   planes.

   The forwarding plane performs per-datagram operations.  The control
   plane contains a keying daemon, such as ISAKMP/IKE, and performs all
   authorization, peer authentication, and key derivation functions.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Forwarding Plane State Machine</span>

   Let the OE gateway maintain a collection of objects -- a superset of
   the security policy database (SPD) specified in [<a href="./rfc2401" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC2401</a>].  For each
   combination of source and destination address, an SPD object exists
   in one of five following states.  Prior to forwarding each datagram,
   the responder uses the source and destination addresses to pick an
   entry from the SPD.  The SPD then determines if and how the packet is
   forwarded.














<span class="grey">Richardson &amp; Redelmeier      Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


         .--------------.
         | nonexistent  |
         |    policy    |
         `--------------'
                |
                | PF_ACQUIRE
                |
                |&lt;---------.
                V          | new packet
         .--------------.  | (maybe resend PF_ACQUIRE)
         |  hold policy |--'
         |              |--.
         `--------------'   \  pass
            |        |       \ msg    .---------.
            |        |        \       V         | forward
            |        |         .-------------.  | packet
     create |        |         | pass policy |--'
     IPsec  |        |         `-------------'
     SA     |        |
            |         \
            |          \
            V           \ deny
      .---------.        \ msg
      | encrypt |         \
      | policy  |          \         ,---------.
      `---------'           \        |         | discard
                             \       V         | packet
                              .-------------.  |
                              | deny policy |--'
                              `-------------'

<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>.  Nonexistent Policy</span>

   If the gateway does not find an entry, then this policy applies.  The
   gateway creates an entry with an initial state of "hold policy" and
   requests keying material from the keying daemon.  The gateway does
   not forward the datagram; rather, it SHOULD attach the datagram to
   the SPD entry as the "first" datagram and retain it for eventual
   transmission in a new state.

<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>.  Hold Policy</span>

   The gateway requests keying material.  If the interface to the keying
   system is lossy (PF_KEY, for instance, can be), the implementation
   SHOULD include a mechanism to retransmit the keying request at a rate
   limited to less than 1 request per second.  The gateway does not
   forward the datagram.  The gateway SHOULD attach the datagram to the
   SPD entry as the "last" datagram, where it is retained for eventual



<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   transmission.  If there is a datagram already stored in this way,
   then that already-stored datagram is discarded.

   The rationale behind saving the "first" and "last" datagrams are as
   follows: The "first" datagram is probably a TCP SYN packet.  Once
   there is keying established, the gateway will release this datagram,
   avoiding the need for the endpoint to retransmit the datagram.  In
   the case where the connection was not a TCP connection, but was
   instead a streaming protocol or a DNS request, the "last" datagram
   that was retained is likely the most recent data.  The difference
   between "first" and "last" may also help the endpoints determine
   which data was dropped while negotiation took place.

<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>.  Pass-Through Policy</span>

   The gateway forwards the datagram using the normal forwarding table.
   The gateway enters this state only by command from the keying daemon,
   and upon entering this state, also forwards the "first" and "last"
   datagrams.

<span class="h4"><a class="selflink" id="section-3.1.4" href="#section-3.1.4">3.1.4</a>.  Deny Policy</span>

   The gateway discards the datagram.  The gateway enters this state
   only by command from the keying daemon, and upon entering this state,
   discards the "first" and "last" datagrams.  An implementation MAY
   provide the administrator with a control to determine if further
   datagrams cause ICMP messages to be generated (i.e., ICMP Destination
   Unreachable, Communication Administratively Prohibited.  type=3,
   code=13).

<span class="h4"><a class="selflink" id="section-3.1.5" href="#section-3.1.5">3.1.5</a>.  Encrypt Policy</span>

   The gateway encrypts the datagram using the indicated security
   association database (SAD) entry.  The gateway enters this state only
   by command from the keying daemon, and upon entering this state,
   releases and forwards the "first" and "last" datagrams using the new
   encrypt policy.

   If the associated SAD entry expires because of byte, packet or time
   limits, then the entry returns to the Hold policy, and an expire
   message is sent to the keying daemon.

   All states may be created directly by the keying daemon while acting
   as a gateway.







<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Keying Daemon -- Initiator</span>

   Let the keying daemon maintain a collection of objects.  Let them be
   called "connections" or "conn"s.  There are two categories of
   connection objects: classes and instances.  A class represents an
   abstract policy (i.e., what could be).  An instance represents an
   actual connection (i.e., what is running at the time).

   Let there be two further subtypes of connections: keying channels
   (Phase 1 SAs) and data channels (Phase 2 SAs).  Each data channel
   object may have a corresponding SPD and SAD entry maintained by the
   datagram state machine.

   For the purposes of opportunistic encryption, there MUST, at least,
   be connection classes known as "deny", "always-clear-text", "OE-
   permissive", and "OE-paranoid".  The latter two connection classes
   define a set of destination prefixes for which opportunistic
   encryption will be attempted.  The administrator MAY set policy
   options in a number of additional places.  An implementation MAY
   create additional connection classes to further refine these
   policies.

   The simplest system may need only the "OE-permissive" connection, and
   would list its own (single) IP address as the source address of this
   policy and the wild-card address 0.0.0.0/0 as the destination IPv4
   address.  That is, the simplest policy is to try opportunistic
   encryption with all destinations.

   This simplest policy SHOULD be offered as a preconfigured default.

   The distinction between permissive and paranoid Opportunistic
   Encryption ("OE-paranoid" below) use will become clear in the state
   transition differences.

   In brief, an OE-permissive policy means to permit traffic to flow in
   the clear when there is a failure to find and/or use the encryption
   keys.  OE-permissive permits the network to function, even if in an
   insecure manner.

   On failure, a paranoid OE ("OE-paranoid") will install a drop policy.
   OE-paranoid permits traffic to flow only when appropriate security is
   available.

   In this description of the keying machine's state transitions, the
   states associated with the keying system itself are omitted because
   they are best documented in the keying system ([<a href="./rfc2407" title="&quot;The Internet IP Security Domain of Interpretation for ISAKMP&quot;">RFC2407</a>], [<a href="./rfc2408" title="&quot;Internet Security Association and key Management Protocol (ISAKMP)&quot;">RFC2408</a>],
   and [<a href="./rfc2409" title="&quot;The Internet key Exchange (IKE)&quot;">RFC2409</a>] for ISAKMP/IKE), and the details are keying system
   specific.  Opportunistic encryption is not dependent upon any



<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   specific keying protocol, but this document does provide requirements
   for those using ISAKMP/IKE to assure that implementations inter-
   operate.

   The state transitions that may be involved in communicating with the
   forwarding plane are omitted.  PF_KEY and similar protocols have
   their own set of states required for message sends and completion
   notifications.

   Finally, the retransmits and recursive lookups that are normal for
   DNS are not included in this description of the state machine.

                         |
                         | PF_ACQUIRE
                         |
                         V
                 .---------------.
                 |  nonexistent  |
                 |  connection   |
                 `---------------'
                  |      |      |
           send   ,      |      \
 expired   pass  /       |       \ send
 conn.     msg  /        |        \ deny
   ^           /         |         \ msg
   |          V          | do       \
 .---------------.       | DNS       \   .---------------.
 |  clear-text   |       | lookup     `-&gt;|     deny      |---&gt;expired
 |  connection   |       | for           |  connection   |  connection
 `---------------'       | destination   `---------------'
    ^ ^                  |                   ^
    | | no record        |                   |
    | | OE-permissive    V                   | no record
    | |            .---------------.         | OE-paranoid
    | `------------|  potential OE |---------'
    |              |  connection   |         ^
    |              `---------------'         |
    |                    |                   |
    |                    | got TXT record    | DNSSEC failure
    |                    | reply             |
    |                    V                   | wrong
    |              .---------------.         | failure
    |              |  authenticate |---------'
    |              | &amp; parse TXT RR|         ^
    | repeated     `---------------'         |
    | ICMP               |                   |
    | failures           | initiate IKE to   |
    | (short timeout)    | responder         |



<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


    |                    V                   |
    | phase-2      .---------------.         | failure
    | failure      |   pending     |---------'
    | (normal      |     OE        |         ^
    |  timeout)    |               |invalid  | phase-2 fail (normal
    |              |               |&lt;--.SPI  |               timeout)
    |              |               |   |     | ICMP failures (short
    |              | +=======+     |---'     |                timeout)
    |              | |  IKE  |     |   ^     |
    `----------------| states|---------------'
                   | +=======+     |   |
                   `---------------'   |
                         | IPsec SA    | invalid SPI
                         | established |
                         V             | rekey time
                   .--------------.    |
                   |   keyed      |&lt;---|------------------------------.
                   |  connection  |----'                              |
                   `--------------'                                   |
                         | timer                                      |
                         |                                            |
                         V                                            |
                   .--------------.     connection still active       |
   clear-text-----&gt;|   expired    |-----------------------------------'
         deny-----&gt;|  connection  |
                   `--------------'
                         | dead connection - deleted
                         V

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Nonexistent Connection</span>

   There is no connection instance for a given source/destination
   address pair.  Upon receipt of a request for keying material for this
   source/destination pair, the initiator searches through the
   connection classes to determine the most appropriate policy.  Upon
   determining an appropriate connection class, an instance object is
   created of that type.  Both of the OE types result in a potential OE
   connection.

   Failure to find an appropriate connection class results in an
   administrator-defined default.

   In each case, when the initiator finds an appropriate class for the
   new flow, an instance connection is made of the class that matched.







<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Clear-Text Connection</span>

   The nonexistent connection makes a transition to this state when an
   always-clear-text class is instantiated, or when an OE-permissive
   connection fails.  During the transition, the initiator creates a
   pass-through policy object in the forwarding plane for the
   appropriate flow.

   Timing out is the only way to leave this state (see <a href="#section-3.2.7">Section 3.2.7</a>).

<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>.  Deny Connection</span>

   The empty connection makes a transition to this state when a deny
   class is instantiated, or when an OE-paranoid connection fails.
   During the transition, the initiator creates a deny policy object in
   the forwarding plane for the appropriate flow.

   Timing out is the only way to leave this state (see <a href="#section-3.2.7">Section 3.2.7</a>).

<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>.  Potential OE Connection</span>

   The empty connection makes a transition to this state when one of
   either OE class is instantiated.  During the transition to this
   state, the initiator creates a hold policy object in the forwarding
   plane for the appropriate flow.

   In addition, when making a transition into this state, DNS lookup is
   done in the reverse-map for a TXT delegation resource record (see
   <a href="#section-5.2">Section 5.2</a>).  The lookup key is the destination address of the flow.

   There are three ways to exit this state:

   1.  DNS lookup finds a TXT delegation resource record.

   2.  DNS lookup does not find a TXT delegation resource record.

   3.  DNS lookup times out.

   Based upon the results of the DNS lookup, the potential OE connection
   makes a transition to the pending OE connection state.  The
   conditions for a successful DNS look are:

   1.  DNS finds an appropriate resource record.

   2.  It is properly formatted according to <a href="#section-5.2">Section 5.2</a>.

   3.  If DNSSEC is enabled, then the signature has been vouched for.




<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   Note that if the initiator does not find the public key present in
   the TXT delegation record, then the public key must be looked up as a
   sub-state.  Only successful completion of all the DNS lookups is
   considered a success.

   If DNS lookup does not find a resource record or if DNS times out,
   then the initiator considers the receiver not OE capable.  If this is
   an OE-paranoid instance, then the potential OE connection makes a
   transition to the deny connection state.  If this is an OE-permissive
   instance, then the potential OE connection makes a transition to the
   clear-text connection state.

   If the initiator finds a resource record, but it is not properly
   formatted, or if DNSSEC is enabled and reports a failure to
   authenticate, then the potential OE connection makes a transition to
   the deny connection state.  This action SHOULD be logged.  If the
   administrator wishes to override this transition between states, then
   an always-clear class can be installed for this flow.  An
   implementation MAY make this situation a new class.

<span class="h5"><a class="selflink" id="section-3.2.4.1" href="#section-3.2.4.1">3.2.4.1</a>.  Restriction on Unauthenticated TXT Delegation Records</span>

   An implementation SHOULD also provide an additional administrative
   control on delegation records and DNSSEC.  This control would apply
   to delegation records (the TXT records in the reverse-map) that are
   not protected by DNSSEC.  Records of this type are only permitted to
   delegate to their own address as a gateway.  When this option is
   enabled, an active attack on DNS will be unable to redirect packets
   to other than the original destination.

<span class="h4"><a class="selflink" id="section-3.2.5" href="#section-3.2.5">3.2.5</a>.  Pending OE Connection</span>

   The potential OE connection makes a transition to this state when the
   initiator determines that all the information required from the DNS
   lookup is present.  Upon entering this state, the initiator attempts
   to initiate keying to the gateway provided.

   Exit from this state occurs with either a successfully created IPsec
   SA or a failure of some kind.  Successful SA creation results in a
   transition to the key connection state.

   Three failures have caused significant problems.  They are clearly
   not the only possible failures from keying.








<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   Note that if there are multiple gateways available in the TXT
   delegation records, then a failure can only be declared after all of
   them have been tried.  Further, creation of a phase 1 SA does not
   constitute success.  A set of phase 2 SAs (a tunnel) is considered
   success.

   The first failure occurs when an ICMP port unreachable is
   consistently received without any other communication, or when there
   is silence from the remote end.  This usually means that either the
   gateway is not alive, or the keying daemon is not functional.  For an
   OE-permissive connection, the initiator makes a transition to the
   clear-text connection, but with a low lifespan.  For an OE-
   pessimistic connection, the initiator makes a transition to the deny
   connection again with a low lifespan.  The lifespan in both cases is
   kept low because the remote gateway may be in the process of
   rebooting or be otherwise temporarily unavailable.

   The length of time to wait for the remote keying daemon to wake up is
   a matter of some debate.  If there is a routing failure, 5 minutes is
   usually long enough for the network to re-converge.  Many systems can
   reboot in that amount of time as well.  However, 5 minutes is far too
   long for most users to wait to hear that they can not connect using
   OE.  Implementations SHOULD make this a tunable parameter.

   The second failure occurs after a phase 1 SA has been created, but
   there is either no response to the phase 2 proposal, or the initiator
   receives a negative notify (the notify must be authenticated).  The
   remote gateway is not prepared to do OE at this time.  As before, the
   initiator makes a transition to the clear-text or the deny connection
   based upon connection class, but this time with a normal lifespan.

   The third failure occurs when there is signature failure while
   authenticating the remote gateway.  This can occur when there has
   been a key roll-over, but DNS has not caught up.  In this case again,
   the initiator makes a transition to the clear-text or the deny
   connection based upon the connection class.  However, the lifespan
   depends upon the remaining time to live in the DNS.  (Note that
   DNSSEC signed resource records have a different expiry time from
   non-signed records.)

<span class="h4"><a class="selflink" id="section-3.2.6" href="#section-3.2.6">3.2.6</a>.  Keyed Connection</span>

   The pending OE connection makes a transition to this state when
   session keying material (the phase 2 SAs) is derived.  The initiator
   creates an encrypt policy in the forwarding plane for this flow.






<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   There are three ways to exit this state.  The first is by receipt of
   an authenticated delete message (via the keying channel) from the
   peer.  This is normal teardown and results in a transition to the
   expired connection state.

   The second exit is by expiry of the forwarding plane keying material.
   This starts a re-key operation with a transition back to pending OE
   connection.  In general, the soft expiry occurs with sufficient time
   left to continue using the keys.  A re-key can fail, which may result
   in the connection failing to clear-text or deny as appropriate.  In
   the event of a failure, the forwarding plane policy does not change
   until the phase 2 SA (IPsec SA) reaches its hard expiry.

   The third exit is in response to a negotiation from a remote gateway.
   If the forwarding plane signals the control plane that it has
   received an unknown SPI from the remote gateway, or an ICMP is
   received from the remote gateway indicating an unknown SPI, the
   initiator should consider that the remote gateway has rebooted or
   restarted.  Since these indications are easily forged, the
   implementation must exercise care.  The initiator should make a
   cautious (rate-limited) attempt to re-key the connection.

<span class="h4"><a class="selflink" id="section-3.2.7" href="#section-3.2.7">3.2.7</a>.  Expiring Connection</span>

   The initiator will periodically place each of the deny, clear-text,
   and keyed connections into this sub-state.  See <a href="#section-3.4">Section 3.4</a> for more
   details of how often this occurs.  The initiator queries the
   forwarding plane for last use time of the appropriate policy.  If the
   last use time is relatively recent, then the connection returns to
   the previous deny, clear-text or keyed connection state.  If not,
   then the connection enters the expired connection state.

   The DNS query and answer that lead to the expiring connection state
   are also examined.  The DNS query may become stale.  (A negative,
   i.e., no such record, answer is valid for the period of time given by
   the MINIMUM field in an attached SOA record.  See [<a href="./rfc1034" title="&quot;Domain names - concepts and facilities&quot;">RFC1034</a>] <a href="#section-4.3.4">section</a>
   <a href="#section-4.3.4">4.3.4</a>.)  If the DNS query is stale, then a new query is made.  If the
   results change, then the connection makes a transition to a new state
   as described in potential OE connection state.

   Note that when considering how stale a connection is, both outgoing
   SPD and incoming SAD must be queried as some flows may be
   unidirectional for some time.

   Also note that the policy at the forwarding plane is not updated
   unless there is a conclusion that there should be a change.





<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


<span class="h4"><a class="selflink" id="section-3.2.8" href="#section-3.2.8">3.2.8</a>.  Expired Connection</span>

   Entry to this state occurs when no datagrams have been forwarded
   recently via the appropriate SPD and SAD objects.  The objects in the
   forwarding plane are removed (logging any final byte and packet
   counts, if appropriate) and the connection instance in the keying
   plane is deleted.

   The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs
   as described in <a href="#section-3.4">Section 3.4</a>.

   Whether or not to delete the phase 1 SAs at this time is left as a
   local implementation issue.  Implementations that do delete the phase
   1 SAs MUST send authenticated delete messages to indicate that they
   are doing so.  There is an advantage to keeping the phase 1 SAs until
   they expire: they may prove useful again in the near future.



































<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Keying Daemon -- Responder</span>

   The responder has a set of objects identical to those of the
   initiator.

   The responder receives an invitation to create a keying channel from
   an initiator.

                   |
                   | IKE main mode
                   |  phase 1
                   V
           .-----------------.
           | unauthenticated |
           |     OE peer     |
           `-----------------'
                   |
                   | lookup KEY RR in in-addr.arpa
                   |             (if ID_IPV4_ADDR)
                   | lookup KEY RR in forward
                   |             (if ID_FQDN)
                   V
           .-----------------.  RR not found
           |   received DNS  |---------------&gt; log failure
           |     reply       |
           `----+--------+---'
             phase 2 |        \      misformatted
            proposal |         `------------------&gt; log failure
                     V
           .----------------.
           |  authenticated |  identical initiator
           |     OE peer    |--------------------&gt; initiator
           `----------------'  connection found    state machine
                 |
                 | look for TXT record for initiator
                 |
                 V
           .---------------.
           |  authorized   |---------------------&gt; log failure
           |    OE peer    |
           `---------------'
                 |
                 |
                 V
            potential OE
            connection in
            initiator state
               machine



<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>.  Unauthenticated OE Peer</span>

   Upon entering this state, the responder starts a DNS lookup for a KEY
   record for the initiator.  The responder looks in the reverse-map for
   a KEY record for the initiator if the initiator has offered an
   ID_IPV4_ADDR, and in the forward map if the initiator has offered an
   ID_FQDN type.  (See <a href="./rfc2407#section-4.6.2.1">[RFC2407] section&nbsp;4.6.2.1</a>.)

   The responder exits this state upon successful receipt of a KEY from
   DNS, and use of the key to verify the signature of the initiator.

   Successful authentication of the peer results in a transition to the
   authenticated OE Peer state.

   Note that the unauthenticated OE peer state generally occurs in the
   middle of the key negotiation protocol.  It is really a form of
   pseudo-state.

<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>.  Authenticated OE Peer</span>

   The peer will eventually propose one or more phase 2 SAs.  The
   responder uses the source and destination address in the proposal to
   finish instantiating the connection state using the connection class
   table.  The responder MUST search for an identical connection object
   at this point.

   If an identical connection is found, then the responder deletes the
   old instance, and the new object makes a transition to the pending OE
   connection state.  This means that new ISAKMP connections with a
   given peer will always use the latest instance, which is the correct
   one if the peer has rebooted in the interim.

   If an identical connection is not found, then the responder makes the
   transition according to the rules given for the initiator: it
   installs appropriate policy: clear, drop, or OE.

   If OE, and the phase 2 ID (source IP) is different than the phase 1
   ID, then additional authorization is required.  A TXT record
   associated with the proposed phase 2 source IP is requested.  This is
   used to confirm authorization for the phase 1 identity to encrypt on
   behalf of the phase 2.  Successful retrieval results in a transition
   to "Authorized OE Peer".

   Note that if the initiator is in OE-paranoid mode and the responder
   is in either always-clear-text or deny, then no communication is
   possible according to policy.  An implementation is permitted to
   create new types of policies such as "accept OE but do not initiate
   it".  This is a local matter.



<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>.  Authorized OE Peer</span>

   This state is entered from the Authenticated OE Peer state, upon
   successful retrieval of the TXT record.  The contents of the record
   are confirmed -- any failures lead to errors, as indicated in <a href="#section-3.2.4">Section</a>
   <a href="#section-3.2.4">3.2.4</a>.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Renewal and Teardown</span>

<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>.  Aging</span>

   A potentially unlimited number of tunnels may exist.  In practice,
   only a few tunnels are used during a period of time.  Unused tunnels
   MUST, therefore, be torn down.  Detecting when tunnels are no longer
   in use is the subject of this section.

   There are two methods for removing tunnels: explicit deletion or
   expiry.

   Explicit deletion requires an IKE delete message.  The deletes MUST
   be authenticated, so both ends of the tunnel must maintain the keying
   channel (phase 1 ISAKMP SA).  An implementation that refuses to
   either maintain or recreate the keying channel SA will be unable to
   use this method.

   The tunnel expiry method simply allows the IKE daemon to expire
   normally without attempting to re-key it.

   Regardless of which method is used to remove tunnels, the
   implementation MUST use a method to determine if the tunnel is still
   in use.  The specifics are a local matter, but the FreeS/WAN project
   uses the following criteria.  These criteria are currently
   implemented in the key management daemon, but could also be
   implemented at the SPD layer using an idle timer.

   Set a short initial (soft) lifespan of 1 minute since many net flows
   last only a few seconds.

   At the end of the lifespan, check to see if the tunnel was used by
   traffic in either direction during the last 30 seconds.  If so,
   assign a longer tentative lifespan of 20 minutes, after which, look
   again.  If the tunnel is not in use, then close the tunnel.

   The expiring state in the key management system (see <a href="#section-3.2.7">Section 3.2.7</a>)
   implements these timeouts.  The timer above may be in the forwarding
   plane, but then it must be resettable.





<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   The tentative lifespan is independent of re-keying; it is just the
   time when the tunnel's future is next considered.  (The term lifespan
   is used here rather than lifetime for this reason.)  Unlike re-
   keying, this tunnel use check is not costly and should happen
   reasonably frequently.

   A multi-step back-off algorithm is not considered worth the effort
   here.

   If the security gateway and the client host are the same, and not a
   Bump-in-the-Stack or Bump-in-the-Wire implementation, tunnel teardown
   decisions MAY pay attention to TCP connection status as reported by
   the local TCP layer.  A still-open TCP connection is almost a
   guarantee that more traffic is expected.  Closing of the only TCP
   connection through a tunnel is a strong hint that no more traffic is
   expected.

<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>.  Teardown and Cleanup</span>

   Teardown should always be coordinated between the two ends of the
   tunnel by interpreting and sending delete notifications.  There is a
   detailed sub-state in the expired connection state of the key manager
   that relates to retransmits of the delete notifications, but this is
   considered to be a keying system detail.

   On receiving a delete for the outbound SAs of a tunnel (or some
   subset of them), tear down the inbound ones also and notify the
   remote end with a delete.  If the local system receives a delete for
   a tunnel that is no longer in existence, then two delete messages
   have crossed paths.  Ignore the delete.  The operation has already
   been completed.  Do not generate any messages in this situation.

   Tunnels are to be considered as bidirectional entities, even though
   the low-level protocols don't treat them this way.

   When the deletion is initiated locally, rather than as a response to
   a received delete, send a delete for (all) the inbound SAs of a
   tunnel.  If the local system does not receive a responding delete for
   the outbound SAs, try re-sending the original delete.  Three tries
   spaced 10 seconds apart seems a reasonable level of effort.  A
   failure of the other end to respond after 3 attempts indicates that
   the possibility of further communication is unlikely.  Remove the
   outgoing SAs.  (The remote system may be a mobile node that is no
   longer present or powered on.)

   After re-keying, transmission should switch to using the new outgoing
   SAs (ISAKMP or IPsec) immediately, and the old leftover outgoing SAs
   should be cleared out promptly (delete should be sent for the



<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   outgoing SAs) rather than waiting for them to expire.  This reduces
   clutter and minimizes confusion for the operator doing diagnostics.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Impacts on IKE</span>

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  ISAKMP/IKE Protocol</span>

   The IKE wire protocol needs no modifications.  The major changes are
   implementation issues relating to how the proposals are interpreted,
   and from whom they may come.

   As opportunistic encryption is designed to be useful between peers
   without prior operator configuration, an IKE daemon must be prepared
   to negotiate phase 1 SAs with any node.  This may require a large
   amount of resources to maintain cookie state, as well as large
   amounts of entropy for nonces, cookies, and so on.

   The major changes to support opportunistic encryption are at the IKE
   daemon level.  These changes relate to handling of key acquisition
   requests, lookup of public keys and TXT records, and interactions
   with firewalls and other security facilities that may be co-resident
   on the same gateway.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Gateway Discovery Process</span>

   In a typical configured tunnel, the address of SG-B is provided via
   configuration.  Furthermore, the mapping of an SPD entry to a gateway
   is typically a 1:1 mapping.  When the 0.0.0.0/0 SPD entry technique
   is used, then the mapping to a gateway is determined by the reverse
   DNS records.

   The need to do a DNS lookup and wait for a reply will typically
   introduce a new state and a new event source (DNS replies) to IKE.
   Although a synchronous DNS request can be implemented for proof of
   concept, experience is that it can cause very high latencies when a
   queue of queries must all timeout in series.

   Use of an asynchronous DNS lookup will also permit overlap of DNS
   lookups with some of the protocol steps.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Self Identification</span>

   SG-A will have to establish its identity.  Use an IPv4 (IPv6) ID in
   phase 1.

   There are many situations where the administrator of SG-A may not be
   able to control the reverse DNS records for SG-A's public IP address.
   Typical situations include dialup connections and most residential-



<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   type broadband Internet access (ADSL, cable-modem) connections.  In
   these situations, a fully qualified domain name that is under the
   control of SG-A's administrator may be used when acting as an
   initiator only.  The FQDN ID should be used in phase 1.  See <a href="#section-5.3">Section</a>
   <a href="#section-5.3">5.3</a> for more details and restrictions.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Public Key Retrieval Process</span>

   Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID
   or an FQDN ID, an IKE daemon needs to examine local caches and
   configuration files to determine if this is part of a configured
   tunnel.  If no configured tunnels are found, then the implementation
   should attempt to retrieve a KEY record from the reverse DNS in the
   case of an IPv4/IPv6 ID, or from the forward DNS in the case of FQDN
   ID.

   It is reasonable that if other non-local sources of policy are used
   (COPS, LDAP), they be consulted concurrently, but that some clear
   ordering of policy be provided.  Note that due to variances in
   latency, implementations must wait for positive or negative replies
   from all sources of policy before making any decisions.

<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  Interactions with DNSSEC</span>

   The implementation described (FreeS/WAN 1.98) neither uses DNSSEC
   directly to explicitly verify the authenticity of zone information,
   nor uses the NSEC records to provide authentication of the absence of
   a TXT or KEY record.  Rather, this implementation uses a trusted path
   to a DNSSEC-capable caching resolver.

   To distinguish between an authenticated and an unauthenticated DNS
   resource record, a stub resolver capable of returning DNSSEC
   information MUST be used.

<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>.  Required Proposal Types</span>

<span class="h4"><a class="selflink" id="section-4.6.1" href="#section-4.6.1">4.6.1</a>.  Phase 1 Parameters</span>

   Main mode MUST be used.

   The initiator MUST offer at least one proposal using some combination
   of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5.  Group 5 SHOULD be
   proposed first.  (See [<a href="./rfc3526" title="&quot;More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)&quot;">RFC3526</a>])

   The initiator MAY offer additional proposals, but the cipher MUST not
   be weaker than 3DES.  The initiator SHOULD limit the number of
   proposals such that the IKE datagrams do not need to be fragmented.




<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   The responder MUST accept one of the proposals.  If any configuration
   of the responder is required, then the responder is not acting in an
   opportunistic way.

   The initiator SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6) of
   the external interface of the initiator for phase 1.  (There is an
   exception, see <a href="#section-5.3">Section 5.3</a>.)  The authentication method MUST be RSA
   public key signatures.  The RSA key for the initiator SHOULD be
   placed into a DNS KEY record in the reverse space of the initiator
   (i.e., using in-addr.arpa or ip6.arpa).

<span class="h4"><a class="selflink" id="section-4.6.2" href="#section-4.6.2">4.6.2</a>.  Phase 2 Parameters</span>

   The initiator MUST propose a tunnel between the ultimate sender
   ("Alice" or "A") and ultimate recipient ("Bob" or "B") using 3DES-CBC
   mode, MD5, or SHA1 authentication.  Perfect Forward Secrecy MUST be
   specified.

   Tunnel mode MUST be used.

   Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32.

   Authorization for the initiator to act on Alice's behalf is
   determined by looking for a TXT record in the reverse-map at Alice's
   IP address.

   Compression SHOULD NOT be mandatory.  It MAY be offered as an option.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  DNS Issues</span>

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Use of KEY Record</span>

   In order to establish their own identities, security gateways SHOULD
   publish their public keys in their reverse DNS via DNSSEC's KEY
   record.  See <a href="./rfc2535#section-3">section&nbsp;3 of RFC 2535</a> [<a href="./rfc2535" title="&quot;Domain Name System Security Extensions&quot;">RFC2535</a>].

   For example:

   KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8

   0x4200: The flag bits, indicating that this key is prohibited for
      confidentiality use (it authenticates the peer only, a separate
      Diffie-Hellman exchange is used for confidentiality), and that
      this key is associated with the non-zone entity whose name is the
      RR owner name.  No other flags are set.

   4: This indicates that this key is for use by IPsec.




<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   1: An RSA key is present.

   AQNJjkKlIk9...nYyUkKK8: The public key of the host as described in
      [<a href="./rfc3110" title="&quot;RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)&quot;">RFC3110</a>].

   Use of several KEY records allows for key roll-over.  The SIG Payload
   in IKE phase 1 SHOULD be accepted if the public key, given by any KEY
   RR, validates it.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Use of TXT Delegation Record</span>

   If, for example, machine Alice wishes SG-A to act on her behalf, then
   she publishes a TXT record to provide authorization for SG-A to act
   on Alice's behalf.  This is done similarly for Bob and SG-B.

   These records are located in the reverse DNS (in-addr.arpa or
   ip6.arpa) for their respective IP addresses.  The reverse DNS SHOULD
   be secured by DNSSEC.  DNSSEC is required to defend against active
   attacks.

   If Alice's address is P.Q.R.S, then she can authorize another node to
   act on her behalf by publishing records at:

      S.R.Q.P.in-addr.arpa

   The contents of the resource record are expected to be a string that
   uses the following syntax, as suggested in <a href="./rfc1464">RFC1464</a> [<a href="./rfc1464" title="&quot;Using the Domain Name System To Store Arbitrary String Attributes&quot;">RFC1464</a>].  (Note
   that the reply to query may include other TXT resource records used
   by other applications.)

      X-IPsec-Server(P)=A.B.C.D public-key

               Figure 2: Format of reverse delegation record

   P: Specifies a precedence for this record.  This is similar to MX
      record preferences.  Lower numbers have stronger preference.

   A.B.C.D: Specifies the IP address of the Security Gateway for this
      client machine.

   public-key: Is the encoded RSA Public key of the Security Gateway.
      The public-key is provided here to avoid a second DNS lookup.  If
      this field is absent, then a KEY resource record should be looked
      up in the reverse-map of A.B.C.D.  The key is transmitted in
      base64 format.

   The fields of the record MUST be separated by whitespace.  This MAY
   be: space, tab, newline, or carriage return.  A space is preferred.



<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   In the case where Alice is located at a public address behind a
   security gateway that has no fixed address (or no control over its
   reverse-map), then Alice may delegate to a public key by domain name.

      X-IPsec-Server(P)=@FQDN public-key

       Figure 3: Format of reverse delegation record (FQDN version)

   P: Is as above.
   FQDN: Specifies the FQDN that the Security Gateway will identify
      itself with.
   public-key: Is the encoded RSA Public key of the Security Gateway.

   If there is more than one such TXT record with strongest (lowest
   numbered) precedence, one Security Gateway is picked arbitrarily from
   those specified in the strongest-preference records.

<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>.  Long TXT Records</span>

   When packed into wire-format, TXT records that are longer than 255
   characters are divided into smaller &lt;character-strings&gt;.  (See
   <a href="./rfc1035#section-3.3">[RFC1035] section&nbsp;3.3</a> and 3.3.14.)  These MUST be reassembled into a
   single string for processing.  Whitespace characters in the base64
   encoding are to be ignored.

<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>.  Choice of TXT Record</span>

   It has been suggested to use the KEY, OPT, CERT, or KX records
   instead of a TXT record.  None is satisfactory.

   The KEY RR has a protocol field that could be used to indicate a new
   protocol, and an algorithm field that could be used to indicate
   different contents in the key data.  However, the KEY record is
   clearly not intended for storing what are really authorizations, it
   is just for identities.  Other uses have been discouraged.

   OPT resource records, as defined in [<a href="./rfc2671" title="&quot;Extension Mechanisms for DNS (EDNS0)&quot;">RFC2671</a>], are not intended to be
   used for storage of information.  They are not to be loaded, cached
   or forwarded.  They are, therefore, inappropriate for use here.

   CERT records [<a href="./rfc2538" title="&quot;Storing Certificates in the Domain Name System (DNS)&quot;">RFC2538</a>] can encode almost any set of information.  A
   custom type code could be used permitting any suitable encoding to be
   stored, not just X.509.  According to the RFC, the certificate RRs
   are to be signed internally, which may add undesirable and
   unnecessary bulk.  Larger DNS records may require TCP instead of UDP
   transfers.





<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   At the time of protocol design, the CERT RR was not widely deployed
   and could not be counted upon.  Use of CERT records will be
   investigated, and may be proposed in a future revision of this
   document.

   KX records are ideally suited for use instead of TXT records, but had
   not been deployed at the time of implementation.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Use of FQDN IDs</span>

   Unfortunately, not every administrator has control over the contents
   of the reverse-map.  Where the initiator (SG-A) has no suitable
   reverse-map, the authorization record present in the reverse-map of
   Alice may refer to a FQDN instead of an IP address.

   In this case, the client's TXT record gives the fully qualified
   domain name (FQDN) in place of its security gateway's IP address.
   The initiator should use the ID_FQDN ID-payload in phase 1.  A
   forward lookup for a KEY record on the FQDN must yield the
   initiator's public key.

   This method can also be used when the external address of SG-A is
   dynamic.

   If SG-A is acting on behalf of Alice, then Alice must still delegate
   authority for SG-A to do so in her reverse-map.  When Alice and SG-A
   are one and the same (i.e., Alice is acting as an end-node) then
   there is no need for this when initiating only.

   However, Alice must still delegate to herself if she wishes others to
   initiate OE to her.  See Figure 3.

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  Key Roll-Over</span>

   Good cryptographic hygiene says that one should replace
   public/private key pairs periodically.  Some administrators may wish
   to do this as often as daily.  Typical DNS propagation delays are
   determined by the SOA Resource Record MINIMUM parameter, which
   controls how long DNS replies may be cached.  For reasonable
   operation of DNS servers, administrators usually want this value to
   be at least several hours, sometimes as a long as a day.  This
   presents a problem: a new key MUST not be used prior to its
   propagation through DNS.

   This problem is dealt with by having the Security Gateway generate a
   new public/private key pair, at least MINIMUM seconds in advance of
   using it.  It then adds this key to the DNS (both as a second KEY




<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   record and in additional TXT delegation records) at key generation
   time.  Note: only one key is allowed in each TXT record.

   When authenticating, all gateways MUST have available all public keys
   that are found in DNS for this entity.  This permits the
   authenticating end to check both the key for "today" and the key for
   "tomorrow".  Note that it is the end which is creating the signature
   (possesses the private key) that determines which key is to be used.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Network Address Translation Interaction</span>

   There are no fundamentally new issues for implementing opportunistic
   encryption in the presence of network address translation.  Rather,
   there are only the regular IPsec issues with NAT traversal.

   There are several situations to consider for NAT.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Co-Located NAT/NAPT</span>

   If a security gateway is also performing network address translation
   on behalf of an end-system, then the packet should be translated
   prior to being subjected to opportunistic encryption.  This is in
   contrast to typically configured tunnels, which often exist to bridge
   islands of private network address space.  The security gateway will
   use the translated source address for phase 2, and so the responding
   security gateway will look up that address to confirm SG-A's
   authorization.

   In the case of NAT (1:1), the address space into which the
   translation is done MUST be globally unique, and control over the
   reverse-map is assumed.  Placing of TXT records is possible.

   In the case of NAPT (m:1), the address will be the security gateway
   itself.  The ability to get KEY and TXT records in place will again
   depend upon whether or not there is administrative control over the
   reverse-map.  This is identical to situations involving a single host
   acting on behalf of itself.  For initiators (but not responders), an
   FQDN-style ID can be used to get around a lack of a reverse-map.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Security Gateway behind a NAT/NAPT</span>

   If there is a NAT or NAPT between the security gateways, then normal
   IPsec NAT traversal problems occur.  In addition to the transport
   problem, which may be solved by other mechanisms, there is the issue
   of what phase 1 and phase 2 IDs to use.  While FQDN could be used
   during phase 1 for the security gateway, there is no appropriate ID
   for phase 2.  Due to the NAT, the end systems live in different IP
   address spaces.



<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  End System behind a NAT/NAPT</span>

   If the end system is behind a NAT (perhaps SG-B), then there is, in
   fact, no way for another end system to address a packet to this end
   system.  Not only is opportunistic encryption impossible, but it is
   also impossible for any communication to be initiated to the end
   system.  It may be possible for this end system to initiate such
   communication.  This creates an asymmetry, but this is common for
   NAPT.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Host Implementations</span>

   When Alice and SG-A are components of the same system, they are
   considered to be a host implementation.  The packet sequence scenario
   remains unchanged.

   Components marked Alice are the upper layers (TCP, UDP, the
   application), and SG-A is the IP layer.

   Note that tunnel mode is still required.

   As Alice and SG-A are acting on behalf of themselves, no TXT based
   delegation record is necessary for Alice to initiate.  She can rely
   on FQDN in a forward map.  This is particularly attractive to mobile
   nodes such as notebook computers at conferences.  To respond,
   Alice/SG-A will still need an entry in Alice's reverse-map.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Multi-Homing</span>

   If there are multiple paths between Alice and Bob (as illustrated in
   the diagram with SG-D), then additional DNS records are required to
   establish authorization.

   In Figure 1, Alice has two ways to exit her network: SG-A and SG-D.
   Previously, SG-D has been ignored.  Postulate that there are routers
   between Alice and her set of security gateways (denoted by the +
   signs and the marking of an autonomous system number for Alice's
   network).  Datagrams may, therefore, travel to either SG-A or SG-D en
   route to Bob.

   As long as all network connections are in good order, it does not
   matter how datagrams exit Alice's network.  When they reach either
   security gateway, the security gateway will find the TXT delegation
   record in Bob's reverse-map, and establish an SA with SG-B.

   SG-B has no problem establishing that either of SG-A or SG-D may
   speak for Alice, because Alice has published two equally weighted TXT
   delegation records:



<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


      X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
      X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==

          Figure 4: Multiple gateway delegation example for Alice

   Alice's routers can now do any kind of load sharing needed.  Both
   SG-A and SG-D send datagrams addressed to Bob through their tunnel to
   SG-B.

   Alice's use of non-equal weight delegation records to show preference
   of one gateway over another, has relevance only when SG-B is
   initiating to Alice.

   If the precedences are the same, then SG-B has a more difficult time.
   It must decide which of the two tunnels to use.  SG-B has no
   information about which link is less loaded, nor which security
   gateway has more cryptographic resources available.  SG-B, in fact,
   has no knowledge of whether both gateways are even reachable.

   The Public Internet's default-free zone may well know a good route to
   Alice, but the datagrams that SG-B creates must be addressed to
   either SG-A or SG-D; they can not be addressed to Alice directly.

   SG-B may make a number of choices:

   1.  It can ignore the problem and round robin among the tunnels.
       This causes losses during times when one or the other security
       gateway is unreachable.  If this worries Alice, she can change
       the weights in her TXT delegation records.
   2.  It can send to the gateway from which it most recently received
       datagrams.  This assumes that routing and reachability are
       symmetrical.
   3.  It can listen to BGP information from the Internet to decide
       which system is currently up.  This is clearly much more
       complicated, but if SG-B is already participating in the BGP
       peering system to announce Bob, the results data may already be
       available to it.
   4.  It can refuse to negotiate the second tunnel.  (It is unclear
       whether or not this is even an option.)
   5.  It can silently replace the outgoing portion of the first tunnel
       with the second one while still retaining the incoming portions
       of both.  Thus, SG-B can accept datagrams from either SG-A or
       SG-D, but send only to the gateway that most recently re-keyed
       with it.







<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   Local policy determines which choice SG-B makes.  Note that even if
   SG-B has perfect knowledge about the reachability of SG-A and SG-D,
   Alice may not be reachable from either of these security gateways
   because of internal reachability issues.

   FreeS/WAN implements option 5.  Implementing a different option is
   being considered.  The multi-homing aspects of OE are not well
   developed and may be the subject of a future document.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Failure Modes</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  DNS Failures</span>

   If a DNS server fails to respond, local policy decides whether or not
   to permit communication in the clear as embodied in the connection
   classes in <a href="#section-3.2">Section 3.2</a>.  It is easy to mount a denial of service
   attack on the DNS server responsible for a particular network's
   reverse-map.  Such an attack may cause all communication with that
   network to go in the clear if the policy is permissive, or fail
   completely if the policy is paranoid.  Please note that this is an
   active attack.

   There are still many networks that do not have properly configured
   reverse-maps.  Further, if the policy is not to communicate, the
   above denial of service attack isolates the target network.
   Therefore, the decision of whether or not to permit communication in
   the clear MUST be a matter of local policy.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  DNS Configured, IKE Failures</span>

   DNS records claim that opportunistic encryption should occur, but the
   target gateway either does not respond on port 500, or refuses the
   proposal.  This may be because of a crash or reboot, a faulty
   configuration, or a firewall filtering port 500.

   The receipt of ICMP port, host or network unreachable messages
   indicates a potential problem, but MUST NOT cause communication to
   fail immediately.  ICMP messages are easily forged by attackers.  If
   such a forgery caused immediate failure, then an active attacker
   could easily prevent any encryption from ever occurring, possibly
   preventing all communication.

   In these situations a log should be produced and local policy should
   dictate if communication is then permitted in the clear.







<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>.  System Reboots</span>

   Tunnels sometimes go down because the remote end crashes,
   disconnects, or has a network link break.  In general there is no
   notification of this.  Even in the event of a crash and successful
   reboot, other SGs don't hear about it unless the rebooted SG has
   specific reason to talk to them immediately.  Over-quick response to
   temporary network outages is undesirable.  Note that a tunnel can be
   torn down and then re-established without any effect visible to the
   user except a pause in traffic.  On the other hand, if one end
   reboots, the other end can't get datagrams to it at all (except via
   IKE) until the situation is noticed.  So a bias toward quick response
   is appropriate, even at the cost of occasional false alarms.

   A mechanism for recovery after reboot is a topic of current research
   and is not specified in this document.

   A deliberate shutdown should include an attempt, using delete
   messages, to notify all other SGs currently connected by phase 1 SAs
   that communication is about to fail.  Again, a remote SG will assume
   this is a teardown.  Attempts by the remote SGs to negotiate new
   tunnels as replacements should be ignored.  When possible, SGs should
   attempt to preserve information about currently-connected SGs in
   non-volatile storage, so that after a crash, an Initial-Contact can
   be sent to previous partners to indicate loss of all previously
   established connections.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Unresolved Issues</span>

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Control of Reverse DNS</span>

   The method of obtaining information by reverse DNS lookup causes
   problems for people who cannot control their reverse DNS bindings.
   This is an unresolved problem in this version, and is out of scope.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Examples</span>

<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>.  Clear-Text Usage (Permit Policy)</span>

   Two example scenarios follow.  In the first example, GW-A (Gateway A)
   and GW-B (Gateway B) have always-clear-text policies, and in the
   second example they have an OE policy.  The clear-text policy serves
   as a reference for what occurs in TCP/IP in the absence of
   Opportunistic Encryption.

   Alice wants to communicate with Bob.  Perhaps she wants to retrieve a
   web page from Bob's web server.  In the absence of opportunistic
   encryptors, the following events occur:



<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


     Alice         SG-A       DNS       SG-B           Bob
      Human or application
      'clicks' with a name.
      (1)

       ------(2)--------------&gt;
       Application looks up
       name in DNS to get
       IP address.

       &lt;-----(3)---------------
       Resolver returns "A" RR
       to application with IP
       address.

      (4)
      Application starts a TCP session
      or UDP session and OS sends
      first datagram

     Alice         SG-A       DNS       SG-B           Bob
          ----(5)-----&gt;
          Datagram is seen at first gateway
          from Alice (SG-A).

                      ----------(6)------&gt;
                      Datagram traverses
                      network.

                                          ------(7)-----&gt;
                                          Datagram arrives
                                          at Bob, is provided
                                          to TCP.

                                         &lt;------(8)------
                                          A reply is sent.

                      &lt;----------(9)------
                      Datagram traverses
                      network.
       &lt;----(10)-----
       Alice receives
       answer.

     Alice         SG-A       DNS       SG-B           Bob
      (11)-----------&gt;
       A second exchange
       occurs.



<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


                      ----------(12)-----&gt;
                                          --------------&gt;
                                         &lt;---------------
                      &lt;-------------------
       &lt;-------------

                Figure 5: Timing of regular transaction

<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>.  Opportunistic Encryption</span>

   In the presence of properly configured opportunistic encryptors, the
   event list is extended.  Only changes are annotated.

   The following symbols are used in the time-sequence diagram:

   -  A single dash represents clear-text datagrams.
   =  An equals sign represents phase 2 (IPsec) cipher-text datagrams.
   ~  A single tilde represents clear-text phase 1 datagrams.
   #  A hash sign represents phase 1 (IKE) cipher-text datagrams.
































<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


     Alice          SG-A      DNS       SG-B           Bob
      (1)
       ------(2)--------------&gt;
       &lt;-----(3)---------------
      (4)----(5)-----&gt;+
                     ----(5B)-&gt;
                     &lt;---(5C)--
                     ~~~~~~~~~~~~~(5D)~~~&gt;
                     &lt;~~~~~~~~~~~~(5E)~~~~
                     ~~~~~~~~~~~~~(5F)~~~&gt;
                     &lt;~~~~~~~~~~~~(5G)~~~~
                     #############(5H)###&gt;
                              &lt;----(5I)---
                              -----(5J)--&gt;
                     &lt;############(5K)####
                     #############(5L)###&gt;
                              &lt;----(5M)---
                              -----(5N)--&gt;
                     &lt;############(5O)####
                     #############(5P)###&gt;
                      ============(6)====&gt;
                                          ------(7)-----&gt;
                                         &lt;------(8)------
                     &lt;==========(9)======
       &lt;-----(10)----
      (11)-----------&gt;
                      ==========(12)=====&gt;
                                          --------------&gt;
                                         &lt;---------------
                      &lt;===================
       &lt;-------------

         Figure 6: Timing of opportunistic encryption transaction


















<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   For the purposes of this section, we will describe only the changes
   that occur between Figure 5 and Figure 6.  This corresponds to time
   points 5, 6, 7, 9, and 10 on the list above.

   At point (5), SG-A intercepts the datagram because this
   source/destination pair lacks a policy (the nonexistent policy
   state).  SG-A creates a hold policy, and buffers the datagram.  SG-A
   requests keys from the keying daemon.

   (5B) DNS query for TXT record.
   (5C) DNS response for TXT record.
   (5D) Initial IKE message to responder.
   (5E) Message 2 of phase 1 exchange.
        SG-B receives the message.  A new connection instance is created
        in the unauthenticated OE peer state.
   (5F) Message 3 of phase 1 exchange.
        SG-A sends a Diffie-Hellman exponent.  This is an internal state
        of the keying daemon.
   (5G) Message 4 of phase 1 exchange.
        SG-B responds with a Diffie-Hellman exponent.  This is an
        internal state of the keying protocol.
   (5H) Message 5 of phase 1 exchange.
        SG-A uses the phase 1 SA to send its identity under encryption.
        The choice of identity is discussed in <a href="#section-4.6.1">Section 4.6.1</a>.  This is
        an internal state of the keying protocol.
   (5I) Responder lookup of initiator key.  SG-B asks DNS for the public
        key of the initiator.  DNS looks for a KEY record by IP address
        in the reverse-map.  That is, a KEY resource record is queried
        for 4.1.1.192.in-addr.arpa (recall that SG-A's external address
        is 192.1.1.4).  SG-B uses the resulting public key to
        authenticate the initiator.  See <a href="#section-5.1">Section 5.1</a> for further
        details.
   (5J) DNS replies with public key of initiator.
        Upon successfully authenticating the peer, the connection
        instance makes a transition to authenticated OE peer on SG-B.
        The format of the TXT record returned is described in
        <a href="#section-5.2">Section 5.2</a>.
        Responder replies with ID and authentication.
        SG-B sends its ID along with authentication material, completing
        the phase 1 negotiation.
   (5L) IKE phase 2 negotiation.
        Having established mutually agreeable authentications (via KEY)
        and authorizations (via TXT), SG-A proposes to create an IPsec
        tunnel for datagrams transiting from Alice to Bob.  This tunnel
        is established only for the Alice/Bob combination, not for any
        subnets that may be behind SG-A and SG-B.





<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   (5M) Authorization for SG-A to speak for Alice.
        While the identity of SG-A has been established, its authority
        to speak for Alice has not yet been confirmed.  SG-B does a
        reverse lookup on Alice's address for a TXT record.
   (5N) Responder determines initiator's authority.
        A TXT record is returned.  It confirms that SG-A is authorized
        to speak for Alice.
        Upon receiving this specific proposal, SG-B's connection
        instance makes a transition into the potential OE connection
        state.  SG-B may already have an instance, and the check is made
        as described above.
   (5O) Responder agrees to proposal.
        SG-B, satisfied that SG-A is authorized, proceeds with the
        phase 2 exchange.
        The responder MUST setup the inbound IPsec SAs before sending
        its reply.
   (5P) Final acknowledgement from initiator.
        The initiator agrees with the responder's choice of proposal and
        sets up the tunnel.  The initiator sets up the inbound and
        outbound IPsec SAs.
        Upon receipt of this message, the responder may now setup the
        outbound IPsec SAs.
   (6)  IPsec succeeds and sets up a tunnel for communication between
        Alice and Bob.

      SG-A sends the datagram saved at step (5) through the newly
      created tunnel to SG-B, where it gets decrypted and forwarded.
      Bob receives it at (7) and replies at (8).  SG-B already has a
      tunnel up with G1 and uses it.  At (9), SG-B has already
      established an SPD entry mapping Bob-&gt;Alice via a tunnel, so this
      tunnel is simply applied.  The datagram is encrypted to SG-A,
      decrypted by SG-A, and passed to Alice at (10).

<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  Security Considerations</span>

<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>.  Configured versus Opportunistic Tunnels</span>

   Configured tunnels are setup using bilateral mechanisms: exchanging
   public keys (raw RSA, DSA, PKIX), pre-shared secrets, or by
   referencing keys that are in known places (distinguished name from
   LDAP, DNS).  These keys are then used to configure a specific tunnel.

   A pre-configured tunnel may be on all the time, or may be keyed only
   when needed.  The endpoints of the tunnel are not necessarily static;
   many mobile applications (road warrior) are considered to be
   configured tunnels.





<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   The primary characteristic is that configured tunnels are assigned
   specific security properties.  They may be trusted in different ways
   relating to exceptions to firewall rules, exceptions to NAT
   processing, and to bandwidth or other quality of service
   restrictions.

   Opportunistic tunnels are not inherently trusted in any strong way.
   They are created without prior arrangement.  As the two parties are
   strangers, there MUST be no confusion of datagrams that arrive from
   opportunistic peers and those that arrive from configured tunnels.  A
   security gateway MUST take care that an opportunistic peer cannot
   impersonate a configured peer.

   Ingress filtering MUST be used to make sure that only datagrams
   authorized by negotiation (and the concomitant authentication and
   authorization) are accepted from a tunnel.  This is to prevent one
   peer from impersonating another.

   An implementation suggestion is to treat opportunistic tunnel
   datagrams as if they arrive on a logical interface distinct from
   other configured tunnels.  As the number of opportunistic tunnels
   that may be created automatically on a system is potentially very
   high, careful attention to scaling should be taken into account.

   As with any IKE negotiation, opportunistic encryption cannot be
   secure without authentication.  Opportunistic encryption relies on
   DNS for its authentication information and, therefore, cannot be
   fully secure without a secure DNS.  Without secure DNS, opportunistic
   encryption can protect against passive eavesdropping but not against
   active man-in-the-middle attacks.

<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>.  Firewalls versus Opportunistic Tunnels</span>

   Typical usage of per datagram access control lists is to implement
   various kinds of security gateways.  These are typically called
   "firewalls".

   Typical usage of a virtual private network (VPN) within a firewall is
   to bypass all or part of the access controls between two networks.
   Additional trust (as outlined in the previous section) is given to
   datagrams that arrive in the VPN.

   Datagrams that arrive via opportunistically configured tunnels MUST
   not be trusted.  Any security policy that would apply to a datagram
   arriving in the clear SHOULD also be applied to datagrams arriving
   opportunistically.





<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


<span class="h3"><a class="selflink" id="section-12.3" href="#section-12.3">12.3</a>.  Denial of Service</span>

   There are several different forms of denial of service that an
   implementor should be concerned with.  Most of these problems are
   shared with security gateways that have large numbers of mobile peers
   (road warriors).

   The design of ISAKMP/IKE, and its use of cookies, defend against many
   kinds of denial of service.  Opportunism changes the assumption that
   if the phase 1 (ISAKMP) SA is authenticated, that it was worthwhile
   creating.  Because the gateway will communicate with any machine, it
   is possible to form phase 1 SAs with any machine on the Internet.

<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>.  Acknowledgements</span>

   Substantive portions of this document are based upon previous work by
   Henry Spencer.  [<a href="#ref-OEspec" title="&quot;Opportunistic Encryption&quot;">OEspec</a>]

   Thanks to Tero Kivinen, Sandy Harris, Wes Hardarker, Robert
   Moskowitz, Jakob Schlyter, Bill Sommerfeld, John Gilmore, and John
   Denker for their comments and constructive criticism.

   Sandra Hoffman and Bill Dickie did the detailed proof reading and
   editing.

<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>.  References</span>

<span class="h3"><a class="selflink" id="section-14.1" href="#section-14.1">14.1</a>.  Normative References</span>

   [<a id="ref-RFC1035">RFC1035</a>]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987.

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC2401">RFC2401</a>]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November 1998.

   [<a id="ref-RFC2407">RFC2407</a>]  Piper, D., "The Internet IP Security Domain of
              Interpretation for ISAKMP", <a href="./rfc2407">RFC 2407</a>, November 1998.

   [<a id="ref-RFC2408">RFC2408</a>]  Maughan, D., Schneider, M., and M. Schertler, "Internet
              Security Association and key Management Protocol
              (ISAKMP)", <a href="./rfc2408">RFC 2408</a>, November 1998.

   [<a id="ref-RFC2409">RFC2409</a>]  Harkins, D. and D. Carrel, "The Internet key Exchange
              (IKE)", <a href="./rfc2409">RFC 2409</a>, November 1998.




<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   [<a id="ref-RFC2535">RFC2535</a>]  Eastlake, D., "Domain Name System Security Extensions",
              <a href="./rfc2535">RFC 2535</a>, March 1999.

   [<a id="ref-RFC3110">RFC3110</a>]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
              Name System (DNS)", <a href="./rfc3110">RFC 3110</a>, May 2001.

<span class="h3"><a class="selflink" id="section-14.2" href="#section-14.2">14.2</a>.  Informative References</span>

   [<a id="ref-IPSECKEY">IPSECKEY</a>] Richardson, M., "A Method for Storing IPsec keying
              Material in DNS", <a href="./rfc4025">RFC 4025</a>, March 2005.

   [<a id="ref-OEspec">OEspec</a>]   H. Spencer and Redelmeier, D., "Opportunistic Encryption",
              paper, <a href="http://www.freeswan.org/oeid/opportunism-spec.txt">http://www.freeswan.org/</a>
              <a href="http://www.freeswan.org/oeid/opportunism-spec.txt">oeid/opportunism-spec.txt</a>, May 2001.

   [<a id="ref-RFC0791">RFC0791</a>]  Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>, September
              1981.

   [<a id="ref-RFC1034">RFC1034</a>]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, <a href="./rfc1034">RFC 1034</a>, November 1987.

   [<a id="ref-RFC1464">RFC1464</a>]  Rosenbaum, R., "Using the Domain Name System To Store
              Arbitrary String Attributes", <a href="./rfc1464">RFC 1464</a>, May 1993.

   [<a id="ref-RFC1812">RFC1812</a>]  Baker, F., "Requirements for IP Version 4 Routers", <a href="./rfc1812">RFC</a>
              <a href="./rfc1812">1812</a>, June 1995.

   [<a id="ref-RFC1984">RFC1984</a>]  IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG
              Statement on Cryptographic Technology and the Internet",
              <a href="./rfc1984">RFC 1984</a>, August 1996.

   [<a id="ref-RFC2367">RFC2367</a>]  McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management
              API, Version 2", <a href="./rfc2367">RFC 2367</a>, July 1998.

   [<a id="ref-RFC2538">RFC2538</a>]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in
              the Domain Name System (DNS)", <a href="./rfc2538">RFC 2538</a>, March 1999.

   [<a id="ref-RFC2663">RFC2663</a>]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations", <a href="./rfc2663">RFC</a>
              <a href="./rfc2663">2663</a>, August 1999.

   [<a id="ref-RFC2671">RFC2671</a>]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", <a href="./rfc2671">RFC</a>
              <a href="./rfc2671">2671</a>, August 1999.

   [<a id="ref-RFC3330">RFC3330</a>]  IANA, "Special-Use IPv4 Addresses", <a href="./rfc3330">RFC 3330</a>, September
              2002.





<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


   [<a id="ref-RFC3445">RFC3445</a>]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
              Resource Record (RR)", <a href="./rfc3445">RFC 3445</a>, December 2002.

   [<a id="ref-RFC3526">RFC3526</a>]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
              Diffie-Hellman groups for Internet Key Exchange (IKE)",
              <a href="./rfc3526">RFC 3526</a>, May 2003.

   [<a id="ref-RFC4033">RFC4033</a>]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", <a href="./rfc4033">RFC</a>
              <a href="./rfc4033">4033</a>, March 2005.

Authors' Addresses

   Michael C. Richardson
   Sandelman Software Works
   470 Dawson Avenue
   Ottawa, ON  K1Z 5V7
   CA

   EMail: mcr@sandelman.ottawa.on.ca
   URI:   <a href="http://www.sandelman.ottawa.on.ca/">http://www.sandelman.ottawa.on.ca/</a>


   D. Hugh Redelmeier
   Mimosa Systems Inc.
   29 Donino Avenue
   Toronto, ON  M4N 2W6
   CA

   EMail: hugh@mimosa.com





















<span class="grey">Richardson &amp; Redelmeier      Informational                     [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc4322">RFC 4322</a>           Opportunistic Encryption using IKE      December 2005</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and at www.rfc-editor.org/copyright.html, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Richardson &amp; Redelmeier      Informational                     [Page 44]
</pre>