<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>

<rfc ipr="full2026" docName="draft-richardson-ipsec-opportunistic-06.txt">

<front>
  <area>Security</area>
  <workgroup>Independent submission</workgroup>
  <title abbrev="opportunistic">
     A method for doing opportunistic encryption with IKE
  </title>

  <author initials="M." surname="Richardson" fullname="Michael C. Richardson">
    <organization abbrev="SSW">Sandelman Software Works</organization>
    <address>
      <postal>   
        <street>470 Dawson Avenue</street>
        <city>Ottawa</city>
        <region>ON</region>
        <code>K1Z 5V7</code>
        <country>CA</country>
      </postal>
      <email>mcr@sandelman.ottawa.on.ca</email>
      <uri>http://www.sandelman.ottawa.on.ca/</uri>
    </address>
  </author>

  <author initials="D.H." surname="Redelmeier"
          fullname="D. Hugh Redelmeier">
    <organization abbrev="Mimosa">Mimosa</organization>
    <address>
      <postal>   
        <city>Toronto</city>
        <region>ON</region>
        <country>CA</country>
      </postal>
      <email>hugh@mimosa.com</email>
    </address>
  </author>

  <author initials="H." surname="Spencer"
          fullname="Henry Spencer">
    <organization abbrev="SP Systems">SP Systems</organization>
    <address>
      <postal>
      	<street>Box 280 Station A</street>
	<city>Toronto</city>
	<region>ON</region>
	<code>M5W 1B2</code>
	<country>Canada</country>
      </postal>
      <email>henry@spsystems.net</email>
    </address>
  </author>

  <date month="February" year="2002"></date>
</front>

<abstract>
  <t>
This document describes opportunistic encryption using IKE and IPsec.
The objective is to allow encryption without any pre-arrangement
specific to the pair of gateways involved. Each gateway administrator
makes local arrangements to support opportunistic encryption. Once
that is done, any two such gateways can communicate securely.
  </t>
  <t>
There are two large payoffs. First, if many machines must communicate
securely, this approach reduces administrative overhead to order N
(number of gateways), rather than the N squared cost to configure each
tunnel separately. Second, it becomes possible to make secure
communication the default, even when the partner is not known in
advance.
</t>
<t>
There are naturally some risks and some costs, which are described.
  </t>
  <t>
  This document is offered up as an Informational RFC.
  </t>
</abstract>

<middle>

<section title="Introduction">

<section title="Motivation">

<t>
The objective of opportunistic encryption is to allow encryption without
any pre-arrangement specific to the pair of gateways involved. Each
gateway administrator makes local arrangements -- specifically, adds
public key information to DNS records -- to support opportunistic
encryption and then enables this feature in the nodes' IPsec stack. 
Once that is done, any two such nodes can communicate securely.
</t>

<t>
This document describes opportunistic encryption as designed and
(to date, partially) implemented by the Linux FreeS/WAN project.
For project information, see www.freeswan.org.
</t>

  <t>
  The Internet Architecture Board (IAB) and Internet Engineering Steering Group
  have taken a strong  stand  that the Internet should use powerful
  encryption to provide security and privacy <xref target="RFC1984" />.  This project attempts to put 
  this policy into practice by providing practical means to implement them.
  </t>

  <t>
The project believes that the IPsec protocols are the best chance to
do that, because they are standardized, widely available and can often
be deployed very easily, without changing hardware or software or
retraining of users. However, the extension to opportunistic encryption
seems necessary, both to help control administrative overheads and
to get IPsec more widely used.
  </t>

  <t>
  The use of "opportunistic encryption" offers the "fax effect". As each person
  installs one for their own use, it becomes more valuable for their neighbors
  to install one too, because there's one more person to use it with. The
  software automatically notices each newly installed box, and doesn't
  require a network administrator to reconfigure it. 
  </t>

  <t>
  This document describes the infrastructure needed to support this effort.
  </t>
 
  <t>
  The term S/WAN is a trademark of RSA Data Systems, and is used with permission
  by this project.
  </t>

</section>

<section title="Types of network traffic">
  <t>
    To aid in understand the relationship between security processing and IPsec
    we divide network traffic into four categories:
    <list style="hanging">
      <t hangText="deny">   networks to which traffic is always forbidden</t>
      <t hangText="permit"> networks to which traffic in the clear is desired</t>
      <t hangText="opportunistic tunnel"> networks to which encryption should be
            done if possible, but communication is done in the clear otherwise</t>
      <t hangText="configured tunnel"> networks to which encryption must be
            done, and communication is never in the clear</t>
    </list>      
  </t>

  <t> 
This document describes the third category. 
The first two categories are provided by traditional firewall devices.
The fourth category is presently the offering of many Virtual Private
    Network (VPN) devices.
  </t>

<t> 
  Category one, denied traffic by IP address, requires no authentication. 
</t>

<t>
  Category two, permitted traffic by IP address, requires no
  authentication. This is the normal default on the Internet.
</t>

<t>
  Category four, encrypt traffic or drop it, requires authentication of the
  end points. As the number of end points is typically bounded and is typically
  under the a single authority, arranging for distribution of
  authentication material, while difficult, does not require any new
  technology. 
</t>
<t>
The mechanism described here provides an additional way to
  distribute the authentication materials, notably a public key method that does not
  require deployment of an X.509 based infrastructure.
</t>
</section>	

<section title="Peer authentication in Opportunistic Encryption">

  <t>
  Opportunistic encryption involves creating tunnels with other nodes that
  are essentially strangers. This is done without any prior bilateral
  arrangement. 
  There is therefore the difficult question of how does one know who one is
  talking to.
  </t>
  <t>
  One possible answer is that one does not know who one is talking to. No useful
  authentication can be done, so do not even try. This mode of operation has
  been given the name "anonymous encryption".  A man-in-the-middle attack can be
  used to thwart the privacy of this communication. This would be an active attack. 
  Without peer authentication, there is no way to prevents this kind of attack.
  </t>

  <t>
  Although a useful mode, it is not the goal of this project. It is a useful
  starting point, but the system should permit additional layers of trust to
  be built upon this system. In the described system, the anonymous
  encryption case is what results without DNSSEC. Were anonymous encryption
  the end goal, simpler methods are available to achieve this goal.
  </t>

  <t>
  However, an essential premise of building private connections with
  strangers is that datagrams received through these opportunistic tunnels
  are no more special than datagrams that arrived in the clear.
  </t>

  <t>
  Unlike in a VPN scenario, these datagrams should not be given any special
  exceptions when it comes to auditing, further authentication or
  firewalling.
  </t>
  
  <t>
  On the outbound side, when initiating opportunistic encryption, it becomes
  a local matter what to do if one fails to setup a tunnel. It may be that
  the packet goes out in the clear, or it may be dropped. This is a local
  configuration matter.
  </t>

  <t>
  In sum, we gain wider privacy (for the Internet at large) at minimal cost:
  the cost is the need to reassess assumptions about the relationship between
  IPsec authentication and further local access control. 
  </t>

  </section>

<section title="Use of RFC2119 terms">
<t>
   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 <xref target="RFC2119" />
</t>
</section>

</section>

<section title="Overview">

  <section title="Reference diagram">

    <figure anchor="networkdiagram" title="Reference Network Diagram">
	   <preamble>The following network diagram is used in the rest of
		this document as the canonical diagram</preamble>
           <artwork>
                      [Q]  [R]          AS2
                       .    .                            
  [A]----+----[SG-A]...+....+....[SG-B]-------[B]
     AS1 |             . PI .
  [D]----+----[SG-D]...+    +....[C]    AS3
             

           </artwork>
           <postamble></postamble>

       </figure>

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

  </section>

  <section title="Terminology">

  <t>
  The following terminology is used in this document:
  </t>

  <list style="hanging">
    <t hangText="security gateway:"> a system that performs IPsec tunnel
    mode encapsulation/decapsulation. [SGx] in the diagram</t>
    <t hangText="Alice:"> node [A] in the diagram. When an IP address is needed, this is 192.1.0.65.</t>
    <t hangText="Bob:"> node [B] in the diagram. When an IP address is needed, this is 192.2.0.66.</t>
    <t hangText="Carol:"> node [C] in the diagram. When an IP address is needed, this is 192.1.1.67.</t>
    <t hangText="Dave:"> node [D] in the diagram. When an IP address is needed, this is 192.3.0.68</t>
    <t hangText="SG-A"> Alice's security gateway. Internally it is 192.1.0.1, externally it is 192.1.1.4.</t>
    <t hangText="SG-B"> Bob's security gateway. Internally it is 192.2.0.1, externally it is 192.1.1.5.</t>
    <t hangText="SG-D"> Dave's security gateway. Also Alice's backup security gateway. Internally it is 192.3.0.1, externally it is 192.1.1.6.</t>
    <t hangText="-"> a single dash represents clear-text datagrams</t>
    <t hangText="="> an equals sign represents phase 2 (IPsec) cipher-text
        datagrams</t> 
    <t hangText="#"> a hash sign represents phase 1 (IKE) cipher-text
        datagrams</t> 
    <t hangText="."> a period represents an untrusted network of unknown
        type</t> 
    <t hangText="configured tunnel:"> Contrast with opportunistic tunnel. A tunnel that
		  is directly/deliberately/hand configured on participating gateways.
		  Configured tunnel are typically given a higher level of
		  trust than opportunistic tunnels.</t> 

    <t hangText="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 does not know what the
		  address for the "road warrior" currently is. </t>

    <t hangText="anonymous encryption:">
	The process of encrypting a session without any knowledge of who the
	other parities are. That is, no authentication of identities is done.</t>

    <t hangText="opportunistic encryption:">
	The process of encrypting a session with authenticated knowledge of
	who the other parties are.</t>

    <t hangText="lifetime:">
        The negotiated period in seconds (bytes or datagrams) which a security
	association will remain alive before needing to be re-keyed.</t>

    <t hangText="lifespan:">
        The effective time 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.</t>
    
    <t hangText="phase 1 SA"> an ISAKMP/IKE security association, sometimes
     also referred to as a keying channel.</t>
    <t hangText="phase 2 SA"> an IPsec security association</t>
    <t hangText="tunnel"> another term for a set of phase 2 SA (one in each direction)</t>

    <t hangText="NAT"> Network Address Translation
    (see <xref target="RFC2663" />)</t>
    <t hangText="NAPT"> Network Address and Port Translation
    (see <xref target="RFC2663" />)</t>

    <t hangText="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.
    </t>

  </list>
  </section>

<section title="Model of Operation">

<t>
The Opportunistic Encryption security gateway ("OE gateway") is a regular
gateway node as described in <xref target="RFC0791" /> section 2.4 and  
<xref target="RFC1009" /> with additional capabilities described here and
in <xref target="RFC2401" />.  
The algorithm described here provides a way to determine, for each datagram,
whether or not to apply an encrypting tunnel transformation to the  
datagram. Thus, two important things that must be determined are whether or
not to tunnel and, if so, to which destination.
</t>
<t>
The OE gateway must also be capable of responding to other OE gateways as a
receiver.
</t>

<section title="Tunnel Authorization">
<t>
The decision as to whether or not to create a tunnel is determined on a
per-destination address basis. Upon receiving a packet with a destination
address not recently seen, the OE gateway performs a lookup in DNS for an
authorization record (see <xref target="TXT"/>). This record is located using
the IP address to perform a search in the in-addr.arpa (IPv4) or ip6.arpa
(IPv6) maps. The presence of an authorization record indicates the desire for
a tunnel to be formed. 
</t>
</section> 

<section title="Tunnel End-point discovery">

<t>
The record further provides the address or name of the
end-point which should be used.
</t>
<t>
The record may also provide the public RSA key of the tunnel end point
itself. This is provided for efficiency only - if this is not present, then
the address or name provided is used to perform a second lookup to find a KEY 
Resource Record.
</t>
<t>
DNSSEC (<xref target="RFC2535"/>) SHOULD be used to provide origin and
integrity protection of the Resource Records involved. Section 
<xref target="nodnssec"/> documents a restriction on the tunnel end point if DNSSEC
signatures are not available for the relevant records.
</t>

</section>

<section title="Caching of authorization results">
<t>
The OE gateway MUST maintain a list of source/destination pairs for which 
Opportunistic Encryption has been attempted for a period of time. Successful
discovery of a tunnel end point SHOULD result in creation of a new security
association bundle between the OE gateway and the discovered tunnel end
point.
</t>

<t>
Failure to discover an appropriate authorization MUST result in creation of a 
forwarding policy entry to either drop or transmit in the clear future
datagrams. This negative cache is necessary so as to avoid repeatedly looking 
up the same information, a possibly lengthly process.
</t>

<t>
OE gateways MUST time out all cache entries (both positive and negative ones) 
periodically. This is done both to remove entries which are no longer
necessary, and to permit changes in authorization policy to be discovered.
</t>
</section>

</section> <!-- "Model of Operation" -->

</section> <!-- "Overview" -->

<section title="Specification">

<t>
The OE gateway is modeled to have a forwarding plane and a control
plane. They are connected by a control channel such as PF_KEY. 
(See <xref target="RFC2367" />)
The forwarding plane performs per-datagram operations. The control plane
contains a keying 
daemon such as ISAKMP/IKE and performs all authorization, authentication and
key derivation functions.  
</t>

<section title="Datagram State Machine">

<t>
Let the OE gateway maintain a collection of objects -- a superset of the
Security Policy Database specific in <xref target="RFC2401" />. For
each combination of source and destination address, one may find an SPD
object in one of six states. Prior to forwarding each datagram, the
source and destination addresses are used to pick an entry from the SPD.
The SPD then determines how, and if, the packet is forwarded.

<section title="Nonexistent policy">
<t>
If there is no entry found, then this policy applies.
An entry is created with an initial state of "Hold policy". A request for
keying material is sent to the keying daemon. The datagram is not forwarded,
rather it is attached to the SPD entry as the  "first" datagram and retained
for eventual transmission in a new state. 
</t>
</section>

<section title="Hold policy">
<t>
A request for keying has been previously made. If the interface to the keying
system is lossy (PF_KEY, for instance, can be) a mechanism to retransmit the
keying request, rate limited to less than 1 request per second SHOULD be
made.
The datagram is not forward. The datagram is attached to the SPD entry as the 
"last" datagram and retained for eventual transmission. If there was
previously a datagram so stored, then it is discarded.
</t>
<t>
The retention of the first attempts to avoid waiting for a TCP retransmit,
as the first datagram is probably a TCP SYN packet. The retention of the last
datagram as well applies to streaming protocols, where it is useful to know
how much data has been lost. These are recommendations.
</t>
</section>

<section title="Pass-through policy">
<t>
The datagram is forwarded using the normal forwarding table. This state is
entered only via command from the keying daemon. Upon entering this state,
the "first" and "last" datagrams are forwarded.
</t>
</section>

<section title="Deny policy">
<t>
The datagram is discarded. This state is entered only via command from the
keying daemon. Upon entering this state, the "first" and "last" datagrams are
discarded. It is a local matter if further datagrams cause ICMP messages
to be generated (i.e. ICMP Administratively denied).
</t>
</section>

<section title="Encrypt policy">
<t>
The datagram is encrypted using the indicated Security Association Database
(SAD) entry.
This state is entered only via command from the keying daemon. Upon entering
this state, the "first" and "last" datagrams are using the new encrypt policy.
</t>
<t>
If the associated SAD entry expires (due to byte, packet or time limits) then
the entry returns to the Hold policy, causing an expire message to
communicated to the keying daemon.
</t>
</section>

All states may be created directly by the keying daemon while acting as a
responder. 
</t>

</section> <!-- "Datagram State Machine" -->


<section anchor="initclasses" title="Keying State Machine - Initiator">
<t>
Let the keying daemon maintain a collection of objects -- let them be
called "connections" (or "conn"s for short). There are two categories of
connection objects: classes and instances. A class connection represents an
abstract policy - what could be. An instance represents an actual connection, 
what is in fact implemented at the time.
</t>

<t>
Let there be two further subtypes of connections: keying channels (aka Phase
1 SAs) and data channels (aka Phase 2 SAs). Each data channel object may have 
a corresponding SPD and SAD entry maintained by the Datagram State Machine.
</t>

<t>
For the purposes of Opportunistic Encryption, there MUST at least be
connection classes known as "deny", "always-clear-text", "OE-permissive",
"OE-paranoid".  
The later two connection classes defines a set of source and/or destination
addresses for which Opportunistic Encryption will be attempted. There are a
number of additional places where the administrator MAY set policy
options. An implementation MAY create additional connection classes so that
these policies may be enacted in a more fine grained fashion.
</t>

<t>
{should the additional classes be given names here? - ed.} <!-- XXX -->
</t>

<t>
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. 
</t>

<t>
The distinction between permissive and paranoid OE use will become clear 
in the state transition differences. In general, a permissive OE will, on
failure, install a pass-through policy, while a paranoid OE will, on failure, 
install a drop policy.
</t>

<t>
In this description of the keying machines state transitions, the states
associated with the keying system itself are omitted. This is done for two
reasons: they are best documented in the keying system 
(<xref target="RFC2407" />, 
<xref target="RFC2408" /> and <xref target="RFC2409" /> for ISAKMP/IKE),
and the details are keying system specific. Opportunistic Encryption is not
dependent upon any specific keying protocol, but this document does provide
requirements for those using ISAKMP/IKE to assure inter-operability.
</t>
<t>
The state transitions that may be involved in communicating with the
forwarding plane are omitted. PF_KEY and similar protocols have their own
state of states required for message sends and completion notifications.
</t>
<t>
Finally, the retransmits and recursive lookups that are normal for DNS are 
not included in this state machine.
</t>

<section title="Nonexistent connection">
<t>
There is no connection for a given source/destination address pair.
Upon receipt of a request for keying material for this particular
source/destination pair, a search is made through the connection classes to
determine the most appropriate policy. Upon determining an appropriate
connection class, then an instance object is created of that type. 
Both of the OE types results in a Potential OE connection.
</t>
<t>Failure to find an appropriate connection class results in an
administrator defined default. 
</t>
<t>
In each case, when an appropriate class is found for the new flow
then an instance connection is made of the type which matched.
</t>
</section>

<section title="clear-text connection">
<t>
A transition is made from the empty connection to this state when an
instance of the always-clear-text class is instantiated, or when an OE-permissive 
connection fails. During the transition, a pass-through policy object is created in the 
forwarding plane for the appropriate flow.
</t>
<t>
The only way to leave this state is due to a timeout; see expiry connection.
</t>
</section>

<section title="Deny connection">
<t>
A transition is made from the empty connection to this state when an
instance of the deny class is instantiated, or when an OE-paranoid connection fails. 
During the transition, a deny policy object is created in the forwarding plane 
for the appropriate flow.  
</t>
<t>
The only way to leave this state is due to a timeout; see expiry connection.
</t>
</section>

<section title="Potential OE connection">
<t>
A transition is made from the empty connection to this state when an
instance of either OE class is instantiated.
During the transition to this state, a hold policy object is created in the 
forwarding plane for the appropriate flow.  
</t>
<t>
In addition, when transitioning into this state, DNS lookup(s) are done in
the reverse map for a TXT delegation resource record. (see <xref target="TXT" />)
The destination address of the flow is used as the lookup key.
</t>
<t>
There are three ways to exit this state: due a timeout in the DNS lookup, and 
via positive or negative replies as to the existence of the TXT delegation
resource record.
</t>
<t>
If there is a resource record found, and it is properly formatted, and if
DNSSEC is enabled - the signature has been vouches for (either through local
confirmation or via trusted path to a recursive DNSSEC server), then there is
a transition to the Pending OE connection state. (Note that if the public key 
is not presented in the TXT delegation record, then it must be looked up as
well as a sub-state. The DNS lookups are not considered a success until all
have completed successfully)
</t>
<t>
If there is no resource record found, or DNS times out then it is to be
considered that this is not an OE capable receiver. If this was an
OE-paranoid instance, then there is a transition to the deny connection.
If this was an OE-permissive instance, then there is a transition to the
clear-text connection.
</t>
<t>
If the resource record is found but is misformed, or if DNSSEC has been
enabled and reports a failure to authenticate, then there should be a
transition to the deny connection. This fact should be logged. If the
administrator wishes to override this, then an always-clear class can be 
installed for this flow. An implementation MAY make this situation a new
class.
</t>
<section anchor="nodnssec" title="Restriction on unauthentication TXT delegation records">
<t>
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.
<!-- This was asked for by Bill Sommerfeld -->
</t>
</section>
</section>

<section title="Pending OE connection">
<t>
A transition is made from the Potential OE connection to this state when 
it has been determined that we have all the information from DNS we would need, and 
should make an attempt to do keying for this connection.  Upon entering this
state, an attempt to initiate keying to the gateway provided is started. 
</t>
<t>
One exits from this state either with a successfully created IPsec SA, or
with a failure of some kind.  Successful SA creation results in a transition
to the Key connection state.
</t>
<t>
There are three failures which are distinguished. They are clearly not the
only possible failures from keying, but these are the ones that have caused
the most problems.
</t>
<t>
Note that if there were multiple gateways available in the TXT delegation
records, then a failure can only be declared after all 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.
</t>
<t>
The first failure is when an ICMP port unreachable is consistently received
without any other communication, or when there is silence from the remote
end. This likely means that the gateway is either not alive, or that the
keying daemon is not functional. For an OE-permissive connection, transition
to the clear-text connection, but with a rather low lifespan. The gateway may
be in the process of rebooting, etc. For an OE-pessimistic connection,
transition to the deny connection, again with a low lifespan.
</t>
<t>
How long is long enough to wait for the remote keying daemon to wake up is
a matter of some debate. 5 minutes is usually long enough for the network to
reconverge if there is a routing failure. Many systems can reboot in that
time as well. However, 5 minutes is far too long for most users to wait to
hear that they can not connect with OE. Implementations SHOULD make this a
tuneable parameter.
</t>
<t>
If a phase 1 SA is created, but there is either no response to the phase 2
proposal, or a negative notify (the notify must be authenticated) is
received, then the remote gateway is not prepared to do OE at this time. As
before transition to clear-text/deny based upon connection class, but this
time with a normal lifespan. 
</t>
<t>
The third type of failure is when there is signature failure authenticating
the remote gateway. In this case, again transition to clear-text/deny based
upon the connection class, but make the timeout depend upon the remaining
time to live in the DNS. (Note that DNSSEC signed resource records have a different
expiry time from non-signed records) One possibility is that there has been a 
key roll-over, but that DNS has not caught up.
<!-- dig @gateway would also work here -->
</t>

</section>

<section anchor="keyed" title="Keyed connection">
<t>
A transition is made from the Pending OE connection to this state when 
session keying material (aka the phase 2 SA) has been formed. An Encrypt
Policy is created in the forwarding plane for this flow.
</t>
<t>
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 Expired connection.
</t>
<t>
The second way is by expiry of the forwarding plane keying material. This
causes a re-key operation to be started with a transition back to Pending OE
connection. In general, the soft expiry will occur with sufficient time left
for the keys to continue to be used. Note that a re-key can fail, which may
result in the connection failing to clear-text or deny as
appropriate. Note that the forwarding plane policy does not change until the
rekeying attempt has failed or succeeded.
</t>
<t>
The third way is via respond to a negotiation from a remote gateway, via
receipt of a indication from the forwarding plane of having received unknown
SPI from the gateway, or an ICMP from the remote gateway indicating an
unknown SPI. Each of these things should be considered a hint that the remote
gateway has rebooted or restarted. Since these can easily be forged, care
muyst be exercised.  A cautious (rate-limited) attempt to re-key the
connection should be done. 
</t>
</section>

<section anchor="expiring" title="Expiring connection">
<t>
Each of the deny, clear-text, and keyed connections will periodically be
placed into this sub-state. See <xref target="teardown" /> for more details
of how often this occurs.
The forwarding plane is queried for last use time of the appropriate
policy. If the use time is relatively recent, then the state returns to the
previous deny, clear-text or keyed connection state. If not, then it enters
the expired connection state.
</t>
<t>
The DNS query and answer that lead to the state in question is also
examined. It may have 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 <xref target="RFC1034" /> section 4.3.4)
If it has become stale, then a new query is made. If a change
in the results are seen, then a transition to a new state is made as
described in Potential OE connection state.
</t>
<t> 
Note that both outgoing SPD and incoming SAD must be queried as some flows
may be unidirectional for some time.
</t>
<t>
Note that the policy at the forwarding plane is not updated unless there
is a conclusion that there should be a change. 
</t>

</section>
<section title="Expired connection state">
<t>
Entry to this state is due to no datagrams being 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. 
</t>
<t>
An ISAKMP/IKE Delete is sent to clean up the phase 2 SAs as described in
<xref target="teardown" />. 
</t>
<t>
A difficult question has been whether or not to also delete the phase 1 SAs
at this time. This 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 some advantage to simply keeping
the phase 1 SAs around until they expire - they may prove useful again in the 
near future.
</t>
</section>

</section> <!-- "Keying State Machine - Initiator" -->

<section title="Keying State Machine - Responder">
<t>
The responder has an identical set of objects as the initiator.
</t>
<t>
The responder gets its first indication that something is happening when it 
receives an invitation to create a keying channel from an initiator. 
</t>

<section title="Unauthenticated OE peer state">
<t>
Upon entering this state, a DNS lookup is done for a KEY record for the
initiator. 
This is done 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 <xref target="RFC2407" /> section 
4.6.2.1.)
</t>
<t>
This state is exited upon successful receipt of a KEY from DNS, and use of it 
to verify the signature of the initiator.
</t>

<!--
<t>
The public key that is retrieved should be stored in stable storage for an
administratively defined period of time, (typically several months if
possible). If a key has previously been stored on disk, then the returned key
should be compared to what has been received, and the key considered valid
only if they match.  
</t>
-->

<t>
Successful authentication of the peer results in a transition to
Authenticated OE Peer.
</t>
<t>
Note that this state generally occurs in the middle of the key negotiation
protocol. It is really a form of pseudo-state.
</t>
</section>

<section title="Authenticated OE Peer">
<t>
The peer will eventually propose one or more phase 2 SAs. The source and
destination address in the proposal are used to initialize the still empty
connection state using the connection class table.
A search for an identical connection object MUST be made at this point. 
</t>

<t> 
If an identical connection is found, then delete the old instance that had
been created, 
and transition this new object 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.
</t>
<t> 
If an identical connection is not found, then transition according to the 
rules given for the initiator.
</t>
<t> 
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.
 </t>
</section>

</section> <!-- "Keying State Machine - Responder" -->

<section anchor="teardown" title="Renewal and Teardown">
  <section title="Aging">
<t>
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 they are no longer in use is the subject of this section.
</t>

<t>
There are two methods in which the tunnel may be removed: by expiring
or with explicit deletion. 
</t>

<t>
Explicit deletion is done with an IKE Delete message. To do this requires
that both ends maintain the key channel (phase 1 ISAKMP SA), as the deletes
MUST be authenticated. An implementation which refuses to either maintain or
recreate the keying channel SA will be unable to use this method.
</t>

<t>
In the expiry method, the tunnel is simply allowed by the IKE daemon to
expire normally, without attempting to re-key it.
</t>

<t>
Regardless of which method is used, a method is required to determine if the
tunnel is still in use.  This is a local matter, but the following criteria
are what is used by the FreeSWAN project. This criteria is currently
implemented in the key management daemon, but could also be implemented at
the SPD layer using an idle timer.

<list style="hanging">
<t hangText="+"> a short initial (soft) lifespan of 1 minute is set. This is
                 done since many net flows in fact last only a few seconds.</t>

<t hangText="+"> at the end of the lifespan, a check is made to see if the
                 tunnel was used by traffic in either direction during the last half of
		 this period. 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.
</t>
</list>

These timeouts are implemented by the Expiring state in the key management
system (see <xref target="expiring" />).
The timer given above may in fact be present in the forwarding plane, 
but it must, in this case be resettable. 
</t>

<t>
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.) 
This should happen reasonably frequently, unlike re-keying, which is
costly and shouldn't be too 
frequent. </t>

<t>
A multi-step back-off algorithm is not considered worth the effort here.
</t>

<t>
If the security gateway and the client host are one and 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
coming, while the demise of the only TCP connection through a tunnel is a
strong hint that no more traffic will transit.
</t>

</section> <!-- "Aging" -->

<section title="Teardown and Cleanup">

<t>
Teardown should always be coordinated with the other end.
This means interpreting and sending Delete notifications. There is some
detailed 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.
</t>

<t>
On receiving a Delete for the outbound SAs of a tunnel (or some subset of
them), tear down the inbound ones too, and notify the other end with a
Delete. If a Delete is received for a tunnel which is no longer in
existence, then two Delete messages have crossed paths. Ignore the Delete -
the operation has already been done. Do not generate any messages in this
situation. 
</t>
<t>
Tunnels need to be considered as bidirectional entities, even though the
low-level protocols don't think of them that way. 
</t>

<t>
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 no responding Delete is
received for the outbound SAs, try re-sending the original
Delete. Three tries spaced 10s apart seems a reasonable
level of effort. A failure for the other end to respond at this point 
likely indicates that no further communication will be possible in any case.
(Likely, it was a mobile node and it is not present or powered on anymore)
</t>

<t>
After re-keying, transmission should switch to using the new
outgoing SAs (ISAKMP or IPsec) immediately, and the old leftover SAs 
should be cleared out promptly (and Deletes sent) rather
than waiting for them to expire. This reduces clutter and
minimizes confusion for the operator doing diagnostics.
</t>

</section>

</section>

</section> <!-- "Specification" -->

<section title="Impacts on IKE">

  <section title="ISAKMP/IKE protocol">
    <t>
    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.
    </t>
    <t>
    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 to for nonces,
    cookies, etc. 
    </t>
    <t>
    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 coresident on the same gateway.
    </t>
  </section>

  <section title="Gateway discovery process">
  <t>
  In a typical configured tunnel situation, the address of SG-B is provided
  via configuration. Furthermore, the mapping of SPD entry to 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.
  </t>
  <t>
  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 done for proof of concept, this will not scale very well.
  </t>
  <t> 
  Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with
  protocol some steps.
  </t>
  </section>

  <section title="Self identification">
  <t>
     SG-A will have to establish its identity. This is done by use of an
     IPv4 ID in phase 1. 
  </t>
  <t> 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-type broadband Internet access
      (ADSL, cable-modem). In these situations, a fully qualified domain
      name which 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 <xref target="fqdn" />
      for more details and restrictions.
  </t>
  </section>

  <section title="Public key Retrieval process">
  <t>
     Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID, or
     an FQDN ID, an IKE daemon will need to examine local caches and
     configuration files to determine if this is part of a configured tunnel.
     If none is 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.
  </t>
  <t> 
     It is reasonable that if other non-local sources of policy are used
     (COPS, LDAP, ...) that they be consulted concurrently, but that some
     clear ordering of policy be provided. Note that due to variances in
     latency, one must wait for positive or negative replies from all sources
     of policy before making any decisions.
  </t>
  </section>
  
  <section title="Interactions with DNSSEC">
  <t>
     The present implementation does not use DNSSEC to explicitly verify
     the authenticity of zone information, or use the NXT records to provide
     authentication of the absence of a TXT or KEY record. These are
     important considerations for practical use.
  </t>
  <t> 
     In practice the verification of the DNSSEC SIG and NXT records will
     typically be done by a trusted DNS server. This process may be
     co-located, or reachable via a trusted path. 
  </t>
     
  </section>

<!--
  <section title="Interactions with COPS">
  <t>
     At this time there is no experience with implementations that interact
     with COPS Policy Decision Points (PDP) <xref target="RFC2748" />. It is
     suggested that it may be 
     appropriate for many of 
     the policy and discovery mechanisms outlined here to be done by a PDP.
     In this context, the IKE daemon present in the Policy Enforcement Point
     (PEP) may not need any modifications.
  </t>
  </section>
-->

  <section title="Recommended proposal types">

    <section anchor="phase1id" title="Phase 1 parameters">
      <t>
        Main mode MUST be used.
      </t>
      <t>
	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.
	<xref target="MODPGROUPS" />
      </t>
      <t>
	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.
      </t>
      <t>
	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. 
      </t>
      <t>
        SG-A SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6), of the external
        interface of SG-A for phase 1. (There is an exception, see <xref
        target="fqdn" />) The authentication method MUST be RSA public key signatures. 
      </t>
      <t>
        The RSA key for SG-A MUST be placed into a DNS KEY record in
	the reverse space of SG-A. (i.e. using in-addr.arpa.)
      </t>
    </section>

    <section anchor="phase2id" title="Phase 2 parameters">
      <t>
        SG-A MUST propose a tunnel between Alice and Bob, using 3DES-CBC
        mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be specified.
      </t>
      <t>
        Tunnel mode MUST be used.
      </t>
      <t>
        Authorization for SG-A to act on Alice's behalf is determined by
        looking for a TXT record in the reverse map at Alice's address.
      </t>
      <t>
        Compression SHOULD NOT be mandatory. It may be offered as an option.
      </t>
    </section>
  </section>

</section>

<section title="DNS issues">
  <section anchor="KEY" title="Use of KEY record">
  <t>
    In order to establish their own identity, SG-A and SG-B must publish
    their public keys in their reverse DNS. This is just done via 
    DNSSEC's KEY record.
    See section 3 of <xref target="RFC2535">RFC 2535</xref>.
  </t>	
  <t>
    <preamble>For example:</preamble>
    <artwork><![CDATA[
KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
]]></artwork>

  <list style="hanging">
  <t hangText="0x4200"> The flag bits, indicating that this key is prohibited
    for use confidentiality (it authenticates the peer only, DH 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.</t>
  <t hangText="4">This indicates that this key is for use by IPsec</t>
  <t hangText="1">An RSA key is present</t>
  <t hangText="AQNJjkKlIk9...nYyUkKK8">the public key of the host as described in <xref target="RFC3110" /></t> 
  </list>
  </t>
  </section>

  <section anchor="TXT" title="Use of TXT delegation record">
    <t>
      A TXT record is published by Alice (Bob) to provide authorization
      for SG-A (SG-B) to act on its behalf. This record is located in the
      reverse DNS (in-addr.arpa) for Alice's IP address. 
      The reverse DNS SHOULD be secured by DNSSEC, when it is
      deployed. DNSSEC is required to defend against active attacks.
    </t>

    <t>
      If Alice's address is P.Q.R.S, then she can authorize another node to
      act on her behalf by publishing records at:
           <artwork><![CDATA[
S.R.Q.P.in-addr.arpa
          ]]></artwork>
    </t>

    <t>
    The contents of the resource record are expected to be a string that
    follows the following syntax, as suggested in <xref target="RFC1464" />.
    (Note that the reply to query may include other TXT resource records from 
    other applications may also be returned.)

    <figure anchor="txtformat" title="Format of reverse delegation record">
           <artwork><![CDATA[
X-IPsec-Server(P)=A.B.C.D KEY
          ]]></artwork>
    </figure>
    </t>

    <list style="hanging"> 
      <t hangText="P:"> the P specifies a precedence for this record.  This is
      similar to MX record preferences.  Lower numbers have stronger
      preference. 
      </t>  

      <t hangText="A.B.C.D:"> specifies the IP address of the Security Gateway
      for this client machine.
      </t>

      <t hangText="KEY:"> is the encoded RSA Public key of the Security
      Gateway. This 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.
      </t> 
    </list>

    <t>
	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:

    <figure anchor="txtfqdnformat"
            title="Format of reverse delegation record (FQDN version">
           <artwork><![CDATA[
X-IPsec-Server(P)=@FQDN KEY
          ]]></artwork>
    </figure>
    </t>

    <list style="hanging"> 
      <t hangText="P:"> is as above.
      </t>  

      <t hangText="FQDN"> specifies the FQDN that the Security Gateway
      will identify itself with. Only useful for initiator.
      </t>

      <t hangText="KEY:"> is the encoded RSA Public key of the Security
      Gateway. </t> 
    </list>

    <t>
	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. 
    </t>

  <section title="Choice of TXT record">
  <t>
	It has been suggested to use the OPT, CERT, KEY or KX records instead of
	a TXT record. 
  </t>
  <t> The KEY RR has a Protocol field which could be used to indicate use
        for a new protocol, and an Algorithm field which could be used to
        indicate different contents in the key data. However, the KEY record
	is not clearly intended for storing what are really authorizations,
	it is just for identities. Other uses have been discouraged.
  </t>
  <t> OPT resource records, as defined in <xref target="RFC2671" /> 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.
  </t>
  <t>
    CERT records <xref target="RFC2538" /> can encode almost any set of
    information. A custom Type code would be used permitting any suitable
    encoding to be stored, not just X.509.  The certificate RR, according to
    the RFC, are to be signed internally, which may add undesirable and unnecessary
    bulk. Larger DNS records may require TCP transfers instead of UDP ones.
  </t>
  <t>
    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 result in a future revision of this document.
  </t>
  <t>
    KX records are ideally suited for this use, but had not been deployed at
    the time of implementation.
<!-- Jakob Schlyter <j@crt.se> to confirm -->
  </t>	
  </section>
  </section>

  <section anchor="fqdn" title="Use of FQDN IDs">
    <t>
      Unfortunately, not every administrator has control over the contents
      of the reverse-map.  The only case where we can work around this is
      where the initiator (SG-A) has no suitable reverse map. In this case, the
      authorization record present in the reverse map of Alice may refer to a
      FQDN instead of an IP address.
    </t>
    <t>
      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. 
    </t>
    <t>
      This method can also be used when the external address of SG-A is
      dynamic. 
    </t>
    <t>
      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. Alice must still delegate to
      herself if she wishes to others to initiator OE to her.
      See <xref target="txtfqdnformat" />

    </t>
    <
  </section> 

<section title="Key rollover">
<t>
Good crypto hygiene says that one should replace public/private key pairs
periodically. Some may wish to do this as often as daily. Typical DNS
propogation 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, one usually wants 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 it propogating through DNS.
</t>
<t>
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 record and to any TXT
delegation records) at key generation time. 
</t>
<t>
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 (possessed the private key) that
determines which key is to be used.
</t>

</section>

<section title="Network Address Translation interaction">
  <t>
     There are no fundamentally new issues for getting opportunistic encryption
     to work in the presence of network address translation. Rather there are 
     just the regular IPsec issues with NAT traversal.
  </t>
  <t>
     There are several situations to consider for NAT:
  </t>
  <section title="Colocated NAT/NAPT">
    <t>
       If SG-A is also performing Network Address Translation on
       behalf of Alice, then the packet should be translated prior to
       being subjected to opportunistic encryption. This is in contrast to
       typical configured tunnel which often exist to bridge islands of 
       private network address space. SG-A will use the translated source
       address for phase 2, and so SG-B will look that address up to
       confirm SG-A's authorization. 
    </t>
    <t> 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 to be a given.
        Placing of TXT records is possible.
    </t>
    <t> In the case of NAPT (m:1), the address will be SG-A. 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 situations involving a single host acting on behalf of
	itself. 

	FQDN style can be used to get around a lack of a reverse map for
	initiators only.
    </t>
  </section>

  <section title="SG-A behind NAT/NAPT">
    <t>
       If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec
       NAT traversal rules would apply. In addition to the transport problem
       which can be solved via proposals like <xref target="ESPUDP" />, there
       is the issue of what phase 1 and phase 2 IDs to use. While FQDN could
       be used during phase 1 for SG-A. An appropriate ID for phase 2
       permits SG-B
       to determine that SG-A was in fact authorized to speak for Alice. 
    </t>
    <t>
       This is only possible if Alice actually has a public IP. It is a
       somewhat
       unusual case where a public network exists behind SG-A,
       while SG-A itself is behind a NAPT. This may occur with mobile networks
       of various kinds that occasionally wind up behind a NAPT.
    </t>
  </section>

  <section title="Bob is behind a NAT/NAPT">
    <t>
       If Bob is behind a NAT (perhaps SG-B), then there is in fact no way for
       Alice to address a packet to Bob. Not only is opportunistic encryption
       impossible, but it is also impossible for Alice to initiate any
       communication to Bob. It may be possible for Bob to initiate in such
       a situation. 
    </t>
  </section>
</section>

<section title="Host implementations">
<t>
  When Alice and SG-A are components of the same system, then this is
  considered to be a host implementation. The scenario remains unchanged
  with respect to packet sequence.
</t>
<t>
  Components marked Alice are simply the upper layers (TCP, UDP, the
  application), and SG-A is the IP layer.
</t>
<t>
  Note that tunnel mode is still recommended. 
</t>
<t>
  As Alice/SG-A are acting on behalf of themselves, no TXT based delegation
  record is necessary for Alice to initiate. She can rely on a FQDN in a
  forward map.
  To respond, Alice/SG-A will still need an entry in her reverse map.
</t>
</section>

<section title="Multihoming">
<t> 
If there are multiple paths between Alice and Bob (such as illustrated in
the diagram with SG-D) then additional DNS records are required to establish
authorization. 
</t>
<t>
In the diagram in <xref target="networkdiagram" />, 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.
</t>
<t>
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. 
</t>
<t>
SG-B has no problem establishing that either of SG-A or SG-D may speak for
Alice, as Alice has published two equally weighted TXT delegation records:
    <figure anchor="txtmultiexample" title="Multiple gateway delegation example">
           <artwork><![CDATA[
X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
          ]]></artwork>
    </figure>
</t>
<t>
Alice's routers can now happily do any kind of load sharing that they might
wish to do. SG-A and SG-D will both send datagrams addressed to Bob through
their tunnel to SG-B. 
</t>
<t>
If Alice wishes to prefer one gateway over another, then Bob should, upon
finding that he has connections to two gateways en route to Alice, prefer the
most recently established one - the precedence values are only valid for an
initiator. It may be that the other one has experienced a failure, which is
why Alice has switch to her less favourable backup.
</t>
<t>
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.  
</t>
<t>
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.
</t>
<t>
There are a number of choices which SG-B may make:
<list style="numbers">
<t>It can ignore the problem and round robin among the tunnels it has. This
      will cause 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.</t>

<t>It can always send to the gateway that it most recently received from. 
      This assumes that routing and reachability is symmetrical.</t>

<t>It can listen to BGP information from the Internet to decide which
      system is currently up. This is clearly a much more complicated thing
      to do, but if SG-B is already doing this because it is participating
      in the BGP peering system to announce Bob, the results data may already
      be available to it. </t>

<t>It can refuse to negotiate the second tunnel. (It is unclear whether or
not this is even an option)</t>

<t>It can silently replace the outgoing portion of the first tunnel with the
second one, while still retaining the incoming portions of both. SG-B can
thus be willing willing to accept datagrams from either SG-A or SG-D, but
sending only to the gateway that most recently rekeyed with it.</t> 
</list>
</t>

<t>
These are decisions left to local policy. Note that even if SG-B has perfect
knowledge about reachability of SG-A and SG-D, Alice may not be reachable
from one or other of these security gateways due to internal reachability
issues. 
</t>

<t>
FreeS/WAN implements option 5. Consideration to implementing a different in
being given. The multihoming aspects of this OE, not well developed and may
be a subject of a future document.
</t>
	
</section>

<section title="Failure modes">
  <section title="DNS failures">
  <t>
  If a DNS server fails to respond, then it is a local policy decision
  whether or not to permit communication in the clear. This is emboddied in
  the connection classes in <xref target="initclasses" />. It should be
  clear that mounting a denial of service attack on the DNS server
  responsible for a particular network's reverse map is an easy thing to do.
  Such an attack may cause all communication with that network to go in
  the clear for a permissive policy, and for communication to fail completely 
  if this is a paranoid policy. Please note that this is an active attack.
  </t>
  <t>
  At the same time, there are still a very large number of networks
  that do not have properly configured reverse maps. Further, the effect of
  the above denial of service attack, if the policy is not to communicate,
  is that the target network becomes isolated. This is why this decision MUST
  be a matter of local policy.
  </t>
  </section>

  <section title="DNS configured, IKE failures">
  <t>
  In this situation, 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 due to a crash/reboot, due to
  misconfiguration, or a firewall filtering port 500.  
  </t>
  <t>
  The receipt of ICMP port,
  host or network unreachable messages should be taken as a sign that there
  is 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 attacker could easily prevent any
  encryption from ever occuring, possibly preventing all communication.
  </t>
  <t>
  It is recommended that in these situations that a clear log be produced
  about the problem. A local policy should dictate if communication is then
  permitted in the clear at this point.
  </t>
  </section>

  <section title="System reboots">
<t>
Tunnels sometimes go down because the other end crashes,  or
disconnects,  or  has  a network link break, and there is no
notice of this in the general case.  (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 out-
ages is undesirable...  but note that a tunnel can  be  torn
down and then re-established without any user-visible effect
except a pause in traffic, whereas if one end  does  reboot,
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.
</t>

<t>
A mechanism for recover after reboot is not specified in this
document as it is a topic of current research.
</t>

<t>
A deliberate shutdown should include an attempt to notify all  other  SGs
currently  connected by phase 1 SAs, using Deletes, that communication is
about to fail.  (Again, these will be taken as  teardowns;  attempts  by  the
other SGs to negotiate new tunnels as replacements should be ignored  at
this  point.) And   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.
</t>

  </section>
</section>

<!--
<section title="Performance Experiences">

    Claudia> Is it useful to point out (or to clarify for our own discussion) any of the
    Claudia> following:

    Claudia> *  how much time this is likely to take on typical current hardware?
    Claudia> *  what steps are likely to be time consuming
    Claudia> *  how any added time could affect a typical transaction, such as hitting 
    Claudia>    a web site
    Claudia> *  any ways to minimize such time delays

  <section title="Introduced latency">
  </section>

  <section title="Cryptographic performance">
  </section>

  <section title="Phase 1 SA performance">
  </section>

</section>
-->

<section title="Unresolved issues">
  <section title="Control of reverse DNS">
  <t>
  The method of obtaining information is by reverse DNS lookup causes
  problems for people who can not control their reverse DNS
  bindings. This is an unresolved problem in this version, and is out
  of scope.
  </t>
  </section>
</section>

<section title="Examples">

<section title="Clear-text usage (permit policy)">

<t>
What follows are two example scenarios. The first is where Gate1 and Gate2
have always-cleartext policies, and the second where they have some OE
policy.
</t>

       <figure anchor="regulartiming" title="Timing of regular transaction">
           <artwork><![CDATA[
  Alice         Gate1      DNS      Gate2           Bob
  Alice         Gate1      DNS      Gate2           Bob
   (1)
    ------(2)-------------->
    <-----(3)---------------
   (4)----(5)----->
                   ----------(6)------>
                                       ------(7)----->
                                      <------(8)------
                   <----------(9)------
    <----(10)-----
   (11)----------->
                   ----------(12)----->
                                       -------------->
                                      <---------------
                   <-------------------
    <-------------
          ]]></artwork>
</figure>

<t>
Alice wants to send a packet to Bob, say a ping packet.
Without the presence of opportunistic encryptors, the following events occur:
<list style="hanging">
<t hangText="(1)">Human or application 'clicks' with a name</t>
<t hangText="(2)">Application looks up name in DNS to get IP address</t>
<t hangText="(3)">Resolver returns A record to application</t>
<t hangText="(4)">Application starts a TCP session or UDP session, OS sends packet</t>
<t hangText="(5)">Packet is seen at first gateway from Alice  (SG-A) (Gate1
transitions through Empty connection to always-clear connection and
instantiates a passthrough policy at the forwarding plane)</t>
<t hangText="(6)">Packet is seen at last gateway before Bob   (SG-B)</t>
<t hangText="(7)">First packet from Alice is seen by Bob</t>
<t hangText="(8)">First return packet is sent by Bob</t>
<t hangText="(9)">Packet is seen at Bob's gateway (Gate2 transitions through
an Empty connection to always-clear connection and instantites a passthrough
policy at the forwarding plane)</t>
<t hangText="(10)">Packet is seen at Alice's gateway</t>
<t hangText="(11)">OS hands packet to application, Alice sends another packet</t>
<t hangText="(12)">a second packet traverses the Internet</t>
</list>
</t>
</section>

<section title="Opportunistic Encryption">

<t>
In the presence of properly configured opportunistic encryptors, the
event list is extended.

<figure anchor="opportunistictiming" title="Timing of Opportunistic Encryption transaction">
           <artwork><![CDATA[
  Alice          SG-A      DNS       SG-B           Bob
   (1)
    ------(2)-------------->
    <-----(3)---------------
   (4)----(5)----->+
                  ----(5B)->
                  <---(5C)--
                  -------------(5D)--->
                  <------------(5E1)---
                  -------------(5E2)-->
                  <------------(5E3)---
                  #############(5E4)##>
                  <############(5E5)###
                           <----(5F1)--
                           -----(5F2)->
                  #############(5G1)##>
                           <----(5H1)--
                           -----(5H2)->
                  <############(5G2)###
                  #############(5G3)##>
                   ============(6)====>
		                       ------(7)----->
                                      <------(8)------
                  <==========(9)======
    <-----(10)----
   (11)----------->
                   ==========(12)=====>
                                       -------------->
                                      <---------------
                   <===================
    <-------------
          ]]></artwork>
</figure>

<list style="hanging">
<t hangText="(1)">Human or application clicks with a name</t>
<t hangText="(2)">Application initiates DNS mapping.</t>
<t hangText="(3)">resolver returns A record to application</t>
<t hangText="(4)">Application starts a TCP session or UDP</t>
<t hangText="(5)">SG (host or SG) sees packet to target, buffers it.</t>
<t hangText="(5B)">SG asks the DNS for TXT record</t>
<t hangText="(5C)">DNS returns TXT record(s)</t>
<t hangText="(5D)">Initial IKE Main Mode Packet goes out</t>
<t hangText="(5E)">IKE ISAKMP phase 1 succeeds</t>
<t hangText="(5F)">SG-B asks the DNS for TXT record to prove SG-A agent for Alice</t>
<t hangText="(5G)">IKE phase 2 negotiation</t>
<t hangText="(5H)">DNS looksup by responder (SG-B)</t>
<t hangText="(6)">buffered packet is sent by SG-A</t>
<t hangText="(7)">packet is received by SG-B, and decrypted, sent to Bob</t>
<t hangText="(8)">Bob replies, packet is seen by SG-B</t>
<t hangText="(9)">SG-B already has tunnel up with SG-A, uses it</t>
<t hangText="(10)">SG-A decrypts packet and give it to Alice</t>
<t hangText="(11)">Alice receives packet. Sends new packet to Bob</t>
<t hangText="(12)">SG-A gets second packet, sees that tunnel is up, uses it</t>
</list>
</t>

  <t>
  For the purposes of this section, we will describe on the changes that
  occur between <xref target="regulartiming" /> and
  <xref target="opportunistictiming" />. This means time points 5, 6, 7, 9 and 10. 
  </t>

  <section title="(5) IPsec packet interception">

    <t>
    At point (5), Security Gateway 1 intercepts the packet due to the
    lack of a policy (the non-existant policy!) for this source/destination
    pair. A hold policy is created, and the packet is buffered. A request is
    sent to the keying daemon for keys. 
    </t>

  </section>

  <section title="(5B) DNS lookup for TXT record">
    <t>
    SG-A's IKE daemon, having looked up the source/destination in the connection
    class list, creates a new Potential OE connection instance. The DNS
    queries are started.
    </t>
  </section>

  <section title="(5C) DNS returns TXT record(s)">

  <t>
  DNS returns properly formed TXT delegation records, and SG-A's IKE daemon
  transitions this instance from Potential OE connection to Pending OE
  connection.
  </t>

    <t>
      For the example above, the returned record might contain:

    <figure anchor="txtexample" title="Example of reverse delegation record">
           <artwork><![CDATA[
X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
          ]]></artwork>
    </figure>
    with SG-B's IP address and public key listed.
    </t>

  </section>

  <section title="(5D) Initial IKE Main Mode Packet goes out">
  <t>Upon entering Pending OE connection, SG-A sends the initial ISAKMP
  message, with proposals, see <xref target="phase1id" />.
  </t>
  </section>

  <section title="(5E1) Message 2 of phase 1 exchange">
  <t>
  SG-B receives the message. A new connection instance is created in the
  Unauthenticated OE Peer state.
  </t>
  </section>

  <section title="(5E2) Message 3 of phase 1 exchange">
  <t>
  SG-A sends a Diffie-Hellman exponent. This is an internal state of the
  keying daemon.
  </t>
  </section>

  <section title="(5E3) Message 4 of phase 1 exchange">
  <t>
  SG-B responds with a Diffie-Hellman exponent. This is an internal state of the
  keying protocol.
  </t>
  </section>

  <section title="(5E4) Message 5 of phase 1 exchange">
  <t>
  SG-A uses the phase 1 SA to send its identity under encryption. 
  The choice of identity is discussed in <xref target="phase1id" />.
  This is an internal state of the keying protocol.
  </t>
  </section>

  <section title="(5F1) Responder lookup of initiator key">
  <t>
  Security Gateway 2 asks DNS for the public key of the initiator. 
  This is done by asking 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)
  The resulting public key is used to authenticate the initiator. See <xref
  target="KEY" /> for further details. 
  </t>
  </section>

<section title="(5F2) DNS replies with public key of initiator">
<t>
Upon successfully authenticating the   peer, the connection instance is
transitioned to Authenticated OE peer on SG-2.
</t>
<t>
The format of the TXT record that is returned is described in
<xref target="TXT" />. 
</t>
</section>

  <section title="(5E5) Responder replies with ID and authentication">
  <t>
    SG-B sends its ID along with authentication material. This is an internal
    state for the keying protocol.
  </t>
  </section>

  <section title="(5G) IKE phase 2">
    <section title="(5G1) Initiator proposes tunnel">
    <t>
    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 for only
    the A/B combination, not for any subnets that may be behind SG-A and SG-B.
    </t>
    </section>

    <section title="(5H1) Responder determines initiator's authority">
    <t>
    While the identity of the SG-A has been established, its authority to
    speak for Alice has not yet been confirmed. This is done by doing a reverse
    lookup on A's address for a TXT record. 
    </t>
    <t>Upon receiving this specific proposal, SG-2 transitions its instance
    into the Potential OE connection state. SG-2 may already have an
    instance, and the check is made as described above.</t>
    </section>
  
    <section title="(5H2) DNS replies with TXT record">
    <t>
      The returned key and IP address should match that of SG-A.
    </t>	
    </section>
    
    <section title="(5G2) Responder agrees to proposal">
    <t>
    Should additional communication occur between, for instance, D and B via
    SG-A and SG-B, a new tunnel (phase 2 SA) would be established. The phase 1 SA
    may be reusable.
    </t>
    <t>SG-A, having successfully keyed the tunnel, now transitions from
    Pending OE connection to Keyed OE connection.
    </t>
    <t>The responder MUST setup inbound IPsec SAs before sending its reply.</t>
    </section>

    <section title="(5G3) Final acknowledgement from initiator">
    <t>
    The initiator agrees with the responder's choice and sets up the tunnel.
    The initiator sets up inbound and outbound IPsec SAs.
    </t>
    <t>
    The proper authorization returned with keys SG-2 to transition its instance
    to the Keyed OE connection. 
    </t>
    <t>Upon receipt of this message, the responder may now setup the outbound
    IPsec SAs</t> 
    </section>
  </section>

  <section title="(6) IPsec succeeds, sets up tunnel for communication between Alice and Bob">
  <t>
  The packet which was saved at step (5) is sent through the newly created
  tunnel to SG-B. Bob receives it at (7) and replies at (8). 
  </t>
  </section>

  <section title="(9) SG-B already has tunnel up with G1, uses it">
  <t>
  At (9), SG-B has already established an SPD entry mapping Bob->Alice via a
  tunnel, so this tunnel is simply applied. The packet is encrypted to SG-A,
  decrypted by SG-A and passed to Alice at (10).
  </t>

  </section>
</section> <!-- OE example -->

</section> <!-- Examples -->

<section anchor="securityconsiderations" title="Security Considerations">

  <section title="Configured vs Opportunistic Tunnels">
<t>
    Configured tunnels are those which 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. 
</t>
<t>
A pre-configured tunnel may be on all the time, or may be keyed only when needed. 
The end points of the tunnel are not necessarily static: many mobile
applications ("road warrior") are considered to be configured tunnels. 
</t>
<t>
The primary consideration is that configured tunnels are assigned specific
security properties. They may be trusted in different ways. This is usually
related to exceptions to firewall rules, exceptions to NAT processing, and to
bandwidth or other quality of service restrictions. 
</t>
<t>
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 can not impersonate a configured peer.
</t>
<t>
Ingress filtering MUST be used to make sure that only packets authorized by
negotiation (and the concomitant authentication and authorization) are
accepted from a tunnel. This is to prevent one peer from impersonating another. 
</t>
<t>
An implementation suggestion is to logically treat opportunistically tunnel
datagrams as if they arrive on a distinct logical interface 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.
</t>
<t>
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, it can protect against passive
eavesdropping, but not against active man-in-the-middle attacks.
</t>
  </section>

  <section title="Firewalls vs Opportunistic Tunnels">
<t>
  Typical usage of per-packet access control lists is to implement various
kinds of security gateways. These are typically called "firewalls". 
</t>
<t>
  Typical usage of 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.
</t>
<t> 
  Datagrams that arrive via opportunistically configured tunnels MUST not be
trusted. Any security policy that would apply to a packet arriving in the
clear SHOULD also be applied to datagrams arriving opportunistically.
</t>
  </section>

  <section title="Denial of Service">
<t>
  There are several different forms of denial of service which an implementor 
  should concern themselves with. Most of these problems are shared with
  security gateways that have large numbers of mobile peers (road warriors). 
</t>
<t>
  The design of ISAKMP/IKE, and its use of cookies, defend against many kinds
  of denial of service. There is an assumption that if the phase 1 (ISAKMP) 
  SA is authenticated, that it was worthwhile creating. Opportunism changes
  this assumption. As the gateway will communicate with anyone, it is
  possible to form phase 1 SAs with any machine on the Internet. 
</t>

</section>
</section>

<section title="IANA Considerations">
<t>
    There are no known numbers which IANA will need to manage.
</t>
</section>

<section title="Acknowledgements">
<t>
	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.
</t>
</section>

</middle>

<back>
<references>
%include.reference.OEspec;
<!-- renumber according to reference order -->
%include.reference.RFC.0791;
%include.reference.RFC.1009;
%include.reference.RFC.1984;
%include.reference.RFC.2119;
<!-- IPsec -->
%include.reference.RFC.2367;
%include.reference.RFC.2401;
%include.reference.RFC.2407;
%include.reference.RFC.2408;
%include.reference.RFC.2409;
<!-- ESPUDP -->
%include.reference.ESPUDP;
<!-- ESPUDP -->
%include.reference.MODPGROUPS;
<!-- DNSSEC -->
%include.reference.RFC.1034;
%include.reference.RFC.2671;
%include.reference.RFC.1464;
%include.reference.RFC.2535;
%include.reference.RFC.3110;
%include.reference.RFC.2538;
<!-- COPS -->
%include.reference.RFC.2748;
<!-- NAT -->
%include.reference.RFC.2663;
</references>
</back>
</rfc>
<!--
  $Id: draft-richardson-ipsec-opportunistic.xml,v 1.17 2002/03/12 21:23:55 mcr Exp $

  $Log: draft-richardson-ipsec-opportunistic.xml,v $
  Revision 1.17  2002/03/12 21:23:55  mcr
  	adjusted definition of default-free zone.
  	moved text on key rollover from format description to new
  	section.

  Revision 1.16  2002/02/22 01:23:21  mcr
  	revisions from MCR (2002/2/18) and net.

  Revision 1.15  2002/02/21 20:44:12  mcr
  	extensive from DHR.

  Revision 1.14  2002/02/10 16:20:39  mcr
  	-05 draft. Many revisions to do "OE system in world of OE systems"
  	view of the universe.

  Revision 1.13  2001/12/20 04:35:22  mcr
  	fixed reference to rfc1984.

  Revision 1.12  2001/12/20 03:35:19  mcr
  	comments from Henry, Tero, and Sandy.

  Revision 1.11  2001/12/19 07:26:22  mcr
  	added comment about KX records.

  Revision 1.10  2001/11/09 04:28:10  mcr
  	fixed some typos with XML, and one s/SG-B/SG-D/.

  Revision 1.9  2001/11/09 04:07:13  mcr
  	expanded section 10: multihoming, with an example.

  Revision 1.8  2001/11/09 02:16:51  mcr
  	added lifetime/lifespan definitions.
  	moved example from 5B to 5C.
  	added reference to phase 1 IDs to 5D.
  	cleared up text in aging section.
  	added text about delegation of DNSSEC activity to a DNS server.
  	spelt out DH group names.
  	added text about ignoring TXT records unless DNSSEC is deployed (somerfeld)
  	added example of TXT delegation using FQDN.
  	clarified some text in NAT interaction section.
  	clarified absense of TXT record need for host implementation

  Revision 1.7  2001/11/08 23:09:37  mcr
  	changed revision of draft to 03.

  Revision 1.6  2001/11/08 19:37:14  mcr
  	fixed some formatting of Aging section.

  Revision 1.5  2001/11/08 19:19:30  mcr
  	fixed address for DHR, updated address for MCR,
  	added reference to original HS/DHR OE specification paper.

  Revision 1.4  2001/11/08 19:08:24  mcr
  	section 10, "Renewal and Teardown" added moved between 4/5, and
  	slightly rewritten.

  Revision 1.3  2001/11/08 18:56:34  mcr
  	sections 4.2, 5.6, 5.7.1 and 6.2 edited as per HS.
  	section 10, "Renewal and Teardown" added.
  	section 11, "Failure modes" completed.

  Revision 1.2  2001/11/05 20:31:31  mcr
  	added section from OE spec on aging and teardown.

  Revision 1.1  2001/11/05 04:27:58  mcr
  	OE draft added to documentation.

  Revision 1.12  2001/10/10 01:12:31  mcr
  	removed impact on DNS servers section.
  	removed nested comments.
  	adjusted data of issue

  Revision 1.11  2001/09/17 02:55:50  mcr
  	outline is now stable.

  Revision 1.5  2001/08/19 02:53:32  mcr
  	version 00d formatted.

  Revision 1.10  2001/08/19 02:34:04  mcr
  	version 00d formatted.

  Revision 1.9  2001/08/19 02:21:54  mcr
  	version 00d

  Revision 1.8  2001/07/20 19:07:06  mcr
    commented out section 1.1

  Revision 1.7  2001/07/20 14:14:22  mcr
  	HS and HD comments.

  Revision 1.6  2001/07/19 00:56:50  mcr
  	version 00b.

  Revision 1.5  2001/07/12 23:57:07  mcr
  	OE ID, 00.


!>
