Load /tmp/tmp.beAMfG4063/strongswan-2.7.3 into

branches/source-dist/debian/strongswan.

27 files changed, 12309 insertions, 30 deletions

diff --git a/CHANGES b/CHANGES
index 4feaa188d..3d92f229a 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,15 @@
+strongswan-2.7.3
+----------------
+
+- "sha" and "sha1" are now treated as synonyms in the ike= and esp=
+  algorithm configuration statements.
+
+- Fixed possible segmentation faults in the eroute, klipsdebug, and 
+  other KLIPS-related auxiliary functions by making the USE_NAT_TRAVERSAL
+  compile-time condition defined in Makefile.inc known in
+  programs/Makefile.program. 
+
+
 strongswan-2.7.2
 ----------------
 
@@ -9,8 +21,8 @@ strongswan-2.7.2
   the state pointer before logging current state information, causing an
   immediate crash of the pluto keying daemon due to a NULL pointer.
 
-  We strongly recommend to update to the 2.7.2 released which fixes this
-  vulnerability to malformed proposal payload that could otherwise be
+  We strongly recommend to update to the 2.7.2 release which fixes this
+  vulnerability to malformed proposal payloads that could otherwise be
   exploited by Denial-of-Service attacks.
 
 
diff --git a/Makefile.ver b/Makefile.ver
index 252fc3bf4..b8f0d8ffd 100644
--- a/Makefile.ver
+++ b/Makefile.ver
@@ -1 +1 @@
-IPSECVERSION=2.7.2
+IPSECVERSION=2.7.3
diff --git a/doc/draft-richardson-ipsec-opportunistic.txt b/doc/draft-richardson-ipsec-opportunistic.txt
new file mode 100644
index 000000000..4c87d857a
--- /dev/null
+++ b/doc/draft-richardson-ipsec-opportunistic.txt
@@ -0,0 +1,2688 @@
+
+
+Independent submission                                     M. Richardson
+Internet-Draft                                                       SSW
+Expires: November 19, 2003                                 D. Redelmeier
+                                                                  Mimosa
+                                                            May 21, 2003
+
+
+     Opportunistic Encryption using The Internet Key Exchange (IKE)
+              draft-richardson-ipsec-opportunistic-11.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on November 19, 2003.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes opportunistic encryption (OE) using the
+   Internet Key Exchange (IKE) and IPsec.  Each system administrator
+   adds new resource records to his or her Domain Name System (DNS) to
+   support opportunistic encryption.  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.
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003            [Page 1]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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.
+
+   This document is offered up as an Informational RFC.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  Specification  . . . . . . . . . . . . . . . . . . . . . . . . 10
+   4.  Impacts on IKE . . . . . . . . . . . . . . . . . . . . . . . . 21
+   5.  DNS issues . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+   6.  Network address translation interaction  . . . . . . . . . . . 28
+   7.  Host implementations . . . . . . . . . . . . . . . . . . . . . 29
+   8.  Multi-homing . . . . . . . . . . . . . . . . . . . . . . . . . 30
+   9.  Failure modes  . . . . . . . . . . . . . . . . . . . . . . . . 32
+   10. Unresolved issues  . . . . . . . . . . . . . . . . . . . . . . 34
+   11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
+   12. Security considerations  . . . . . . . . . . . . . . . . . . . 42
+   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 44
+   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 45
+       Normative references . . . . . . . . . . . . . . . . . . . . . 46
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47
+       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 48
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003            [Page 2]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+1. Introduction
+
+1.1 Motivation
+
+   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
+   mostly implemented by the Linux FreeS/WAN project.  For project
+   information, see http://www.freeswan.org.
+
+   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 [4].
+   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 - as 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.
+
+   The term S/WAN is a trademark of RSA Data Systems, and is used with
+   permission by this project.
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003            [Page 3]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+1.2 Types of network traffic
+
+   To aid in understanding the relationship between security processing
+   and IPsec we divide network traffic into four categories:
+
+   * Deny: networks to which traffic is always forbidden.
+
+   * Permit: networks to which traffic in the clear is permitted.
+
+   * Opportunistic tunnel: networks to which traffic is encrypted if
+      possible, but otherwise is in the clear or fails depending on the
+      default policy in place.
+
+   * Configured tunnel: networks to which traffic must be encrypted, and
+      traffic in the clear is never permitted.
+
+   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, encrypt traffic or drop it, requires authentication of
+   the end points.  As the number of end points 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 provides an additional way
+   to distribute the authentication materials, that of a public key
+   method that does not require deployment of an X.509 based
+   infrastructure.
+
+   Current Virtual Private Networks can often be replaced by an "OE
+   paranoid" policy as described herein.
+
+1.3 Peer authentication in opportunistic encryption
+
+   Opportunistic encryption creates tunnels between nodes that are
+   essentially strangers.  This is done without any prior bilateral
+   arrangement.  There is, therefore, the difficult question of how one
+   knows to whom one is talking.
+
+   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.
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003            [Page 4]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   Although 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 desireable goal.
+   The latter 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.
+
+   However, 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.  It may
+   be that the packet goes out in the clear, or it may be dropped.
+
+1.4 Use of RFC2119 terms
+
+   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 [5]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003            [Page 5]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+2. Overview
+
+2.1 Reference diagram
+
+   ---------------------------------------------------------------------
+
+   The following network diagram is used in the rest of this document as
+   the canonical diagram:
+
+                             [Q]  [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 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/B is an independent
+   organization, AS2.  Nodes Q and R are nodes on the Internet.  PI is
+   the Public Internet ("The Wild").
+
+2.2 Terminology
+
+   The following terminology is used in this document:
+
+   Security 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.
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003            [Page 6]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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.
+
+   -  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.
+
+   .  A period represents an untrusted network of unknown type.
+
+   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 parties are.
+
+   Lifetime: the period in seconds (bytes or datagrams) for which a
+      security association will remain alive before needing to be re-
+      keyed.
+
+   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
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003            [Page 7]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+      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 [20]).
+
+   NAPT: Network Address and Port Translation (see [20]).
+
+   AS: an autonomous system (AS) is a group of systems (a network) that
+      are under the administrative control of a single organization.
+
+   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.
+
+
+2.3 Model of operation
+
+   The opportunistic encryption security gateway (OE gateway) is a
+   regular gateway node as described in [2] section 2.4 and [3] with the
+   additional capabilities described here and in [7].  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 end
+   point which should be used.
+
+2.3.1 Tunnel authorization
+
+   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 Section 5.2).
+   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.
+
+2.3.2 Tunnel end-point discovery
+
+   The authorization resource record also provides the address or name
+   of the tunnel end point which should be used.
+
+   The record may also provide the public RSA key of the tunnel end
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003            [Page 8]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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 end point address or name.
+
+   Origin and integrity protection of the resource records is provided
+   by DNSSEC ([16]).  Section 3.2.4.1 documents an optional restriction
+   on the tunnel end point if DNSSEC signatures are not available for
+   the relevant records.
+
+2.3.3 Caching of authorization results
+
+   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 drop or transmit 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 Section 3.4.
+   This removes entries that are no longer being used and permits the
+   discovery of changes in authorization policy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003            [Page 9]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+3. Specification
+
+   The OE gateway is modeled to have a forwarding plane and a control
+   plane.  A control channel, such as PF_KEY, connects the two planes.
+   (See [6].) 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.
+
+3.1 Datagram state machine
+
+   Let the OE gateway maintain a collection of objects -- a superset of
+   the security policy database (SPD) specified in [7].  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.
+
+3.1.1 Non-existent policy
+
+   If the responder does not find an entry, then this policy applies.
+   The responder creates an entry with an initial state of "hold policy"
+   and requests keying material from the keying daemon.  The responder
+   does not forward the datagram, rather it attaches the datagram to the
+   SPD entry as the  "first" datagram and retains it for eventual
+   transmission in a new state.
+
+3.1.2 Hold policy
+
+   The responder 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
+   responder does not forward the datagram.  It attaches the datagram to
+   the SPD entry as the "last" datagram where it is retained for
+   eventual transmission.  If there is a datagram already so stored,
+   then that already stored datagram is discarded.
+
+   Because the "first" datagram is probably a TCP SYN packet, the
+   responder retains the "first" datagram in an attempt to avoid waiting
+   for a TCP retransmit.  The responder retains the "last" datagram in
+   deference to streaming protocols that find it useful to know how much
+   data has been lost.  These are recommendations to decrease latency.
+   There are no operational requirements for this.
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 10]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+3.1.3 Pass-through policy
+
+   The responder forwards the datagram using the normal forwarding
+   table.  The responder enters this state only by command from the
+   keying daemon, and upon entering this state, also forwards the
+   "first" and "last" datagrams.
+
+3.1.4 Deny policy
+
+   The responder discards the datagram.  The responder enters this state
+   only by command from the keying daemon, and upon entering this state,
+   discards the "first" and "last" datagrams.  Local administration
+   decides if further datagrams cause ICMP messages to be generated
+   (i.e.  ICMP Destination Unreachable, Communication Administratively
+   Prohibited.  type=3, code=13).
+
+3.1.5 Encrypt policy
+
+   The responder encrypts the datagram using the indicated security
+   association database (SAD) entry.  The responder 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 responder.
+
+3.2 Keying state machine - initiator
+
+   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 - what could be.  An instance represents an actual
+   connection - what is implemented 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 source and/or destination addresses for which
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 11]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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.
+
+   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.
+
+   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 ([8], [9] and [10] 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 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.
+
+3.2.1 Nonexistent connection
+
+   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 which matched.
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 12]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+3.2.2 Clear-text connection
+
+   The non-existent 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 Section 3.2.7).
+
+3.2.3 Deny connection
+
+   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 Section 3.2.7).
+
+3.2.4 Potential OE connection
+
+   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
+   Section 5.2).  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 Section 5.2
+
+   3.  if DNSSEC is enabled, then the signature has been vouched for.
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 13]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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 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 should make 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.
+
+3.2.4.1 Restriction on unauthenticated TXT delegation records
+
+   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.
+
+3.2.5 Pending OE connection
+
+   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 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.
+
+   Three failures have caused significant problems.  They are clearly
+   not the only possible failures from keying.
+
+   Note that if there are 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
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 14]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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 than non-
+   signed records.)
+
+3.2.6 Keyed connection
+
+   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.
+
+   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.
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 15]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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 to use 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.
+
+3.2.7 Expiring connection
+
+   The initiator will periodically place each of the deny, clear-text,
+   and keyed connections into this sub-state.  See Section 3.4 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 [12] section
+   4.3.4.) 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.
+
+3.2.8 Expired connection
+
+   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
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 16]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   plane is deleted.
+
+   The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs
+   as described in Section 3.4.
+
+   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.
+
+3.3 Keying state machine - responder
+
+   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.
+
+3.3.1 Unauthenticated OE peer
+
+   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 [8] section 4.6.2.1.)
+
+   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.
+
+3.3.2 Authenticated OE Peer
+
+   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
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 17]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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.
+
+   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.
+
+3.4 Renewal and teardown
+
+3.4.1 Aging
+
+   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.  As the deletes
+   MUST be authenticated, both ends of the tunnel must maintain the key
+   channel (phase 1 ISAKMP SA).  An implementation which 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 requires 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.
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 18]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   The expiring state in the key management system (see Section 3.2.7)
+   implements these timeouts.  The timer above may be in the forwarding
+   plane, but then it must be re-settable.
+
+   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.
+
+3.4.2 Teardown and cleanup
+
+   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 which 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.)
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 19]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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
+   outgoing SAs) rather than waiting for them to expire.  This reduces
+   clutter and minimizes confusion for the operator doing diagnostics.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 20]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+4. Impacts on IKE
+
+4.1 ISAKMP/IKE protocol
+
+   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.
+
+4.2 Gateway discovery process
+
+   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.
+
+4.3 Self identification
+
+   SG-A will have to establish its identity.  Use an IPv4 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-
+   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 Section
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 21]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   5.3 for more details and restrictions.
+
+4.4 Public key retrieval process
+
+   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 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.
+
+4.5 Interactions with DNSSEC
+
+   The implementation described (1.98) neither uses DNSSEC directly to
+   explicitly verify the authenticity of zone information, nor uses the
+   NXT 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.
+
+4.6 Required proposal types
+
+4.6.1 Phase 1 parameters
+
+   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.  [11]
+
+   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.
+
+   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.
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 22]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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
+   Section 5.3.) The authentication method MUST be RSA public key
+   signatures.  The RSA key for SG-A SHOULD be placed into a DNS KEY
+   record in the reverse space of SG-A (i.e.  using in-addr.arpa).
+
+4.6.2 Phase 2 parameters
+
+   SG-A MUST propose a tunnel between Alice and Bob, 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 SG-A to act on Alice's behalf is determined by
+   looking for a TXT record in the reverse-map at Alice's address.
+
+   Compression SHOULD NOT be mandatory.  It may be offered as an option.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 23]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+5. DNS issues
+
+5.1 Use of KEY record
+
+   In order to establish their own identities, SG-A and SG-B SHOULD
+   publish their public keys in their reverse DNS via DNSSEC's KEY
+   record.  See section 3 of RFC 2535 [16].
+
+   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.
+
+   1: An RSA key is present.
+
+   AQNJjkKlIk9...nYyUkKK8: The public key of the host as described in
+      [17].
+
+   Use of several KEY records allows for key rollover.  The SIG Payload
+   in IKE phase 1 SHOULD be accepted if the public key given by any KEY
+   RR validates it.
+
+5.2 Use of TXT delegation record
+
+   Alice publishes a TXT record to provide authorization for SG-A to act
+   on Alice's behalf.  Bob publishes a TXT record to provide
+   authorization for SG-B to act on Bob's behalf.  These records are
+   located in the reverse DNS (in-addr.arpa) for their respective IP
+   addresses.  The reverse DNS SHOULD be secured by DNSSEC, when it is
+   deployed.  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 [15].  (Note that the
+   reply to query may include other TXT resource records used by other
+   applications.)
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 24]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   ---------------------------------------------------------------------
+
+
+   X-IPsec-Server(P)=A.B.C.D 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.
+
+   KEY: Is the encoded RSA Public key of the Security Gateway.  The 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 pieces of the record are separated by any whitespace (space, tab,
+   newline, carriage return).  An ASCII space SHOULD be used.
+
+   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 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.
+
+   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.
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 25]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+5.2.1 Long TXT records
+
+   When packed into transport format, TXT records which are longer than
+   255 characters are divided into smaller <character-strings>.  (See
+   [13] section 3.3 and 3.3.14.) These MUST be reassembled into a single
+   string for processing.  Whitespace characters in the base64 encoding
+   are to be ignored.
+
+5.2.2 Choice of TXT record
+
+   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 which could be used to indicate a new
+   protocol, and an algorithm field which 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 [14] 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 [18] 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.
+
+   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.
+
+5.3 Use of FQDN IDs
+
+   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
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 26]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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.
+
+5.4 Key roll-over
+
+   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 it
+   propagating 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
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 27]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+6. Network address translation interaction
+
+   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.
+
+6.1 Co-located NAT/NAPT
+
+   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 typically
+   configured tunnels 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 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 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 to 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.
+
+6.2 SG-A behind NAT/NAPT
+
+   If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec
+   NAT traversal rules apply.  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 SG-A, there is no appropriate ID for phase 2 that permits
+   SG-B to determine that SG-A is in fact authorized to speak for Alice.
+
+6.3 Bob is behind a NAT/NAPT
+
+   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.  This creates an asymmetry, but this is
+   common for NAPT.
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 28]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+7. Host implementations
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 29]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+8. Multi-homing
+
+   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:
+
+   ---------------------------------------------------------------------
+
+
+   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
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 30]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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.  SG-B can, thus, accept datagrams from either SG-A or
+       SG-D, but send only to the gateway that most recently re-keyed
+       with it.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 31]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+9. Failure modes
+
+9.1 DNS failures
+
+   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 Section 3.2.  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.
+
+9.2 DNS configured, IKE failures
+
+   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 clear log should be produced and local policy
+   should dictate if communication is then permitted in the clear.
+
+9.3 System reboots
+
+   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
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 32]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   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 deletes, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 33]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+10. Unresolved issues
+
+10.1 Control of reverse DNS
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 34]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+11. Examples
+
+11.1 Clear-text usage (permit policy)
+
+   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.
+
+   ---------------------------------------------------------------------
+
+
+     Alice         SG-A       DNS       SG-B           Bob
+      (1)
+       ------(2)-------------->
+       <-----(3)---------------
+      (4)----(5)----->
+                      ----------(6)------>
+                                          ------(7)----->
+                                         <------(8)------
+                      <----------(9)------
+       <----(10)-----
+      (11)----------->
+                      ----------(12)----->
+                                          -------------->
+                                         <---------------
+                      <-------------------
+       <-------------
+
+                Figure 5: Timing of regular transaction
+
+   ---------------------------------------------------------------------
+
+   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:
+
+   (1) Human or application 'clicks' with a name.
+
+   (2) Application looks up name in DNS to get IP address.
+
+   (3) Resolver returns A record to application.
+
+   (4) Application starts a TCP session or UDP session and OS sends
+      datagram.
+
+   (5) Datagram is seen at first gateway from Alice (SG-A).  (SG-A makes
+      a transition through Empty connection to always-clear connection
+      and instantiates a pass-through policy at the forwarding plane.)
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 35]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   (6) Datagram is seen at last gateway before Bob (SG-B).
+
+   (7) First datagram from Alice is seen by Bob.
+
+   (8) First return datagram is sent by Bob.
+
+   (9) Datagram is seen at Bob's gateway.  (SG-B makes a transition
+      through Empty connection to always-clear connection and
+      instantiates a pass-through policy at the forwarding plane.)
+
+   (10) Datagram is seen at Alice's gateway.
+
+   (11) OS hands datagram to application.  Alice sends another datagram.
+
+   (12) A second datagram traverses the Internet.
+
+
+11.2 Opportunistic encryption
+
+   In the presence of properly configured opportunistic encryptors, the
+   event list is extended.
+
+   ---------------------------------------------------------------------
+
+
+     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)------
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 36]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+                     <==========(9)======
+       <-----(10)----
+      (11)----------->
+                      ==========(12)=====>
+                                          -------------->
+                                         <---------------
+                      <===================
+       <-------------
+
+        Figure 6: Timing of opportunistic encryption transaction
+
+   ---------------------------------------------------------------------
+
+   (1) Human or application clicks with a name.
+
+   (2) Application initiates DNS mapping.
+
+   (3) Resolver returns A record to application.
+
+   (4) Application starts a TCP session or UDP.
+
+   (5) SG-A (host or SG) sees datagram to target, and buffers it.
+
+   (5B) SG-A asks DNS for TXT record.
+
+   (5C) DNS returns TXT record(s).
+
+   (5D) Initial IKE Main Mode Packet goes out.
+
+   (5E) IKE ISAKMP phase 1 succeeds.
+
+   (5F) SG-B asks DNS for TXT record to prove SG-A is an agent for
+      Alice.
+
+   (5G) IKE phase 2 negotiation.
+
+   (5H) DNS lookup by responder (SG-B).
+
+   (6) Buffered datagram is sent by SG-A.
+
+   (7) Datagram is received by SG-B, decrypted, and sent to Bob.
+
+   (8) Bob replies, and datagram is seen by SG-B.
+
+   (9) SG-B already has tunnel up with SG-A, and uses it.
+
+   (10) SG-A decrypts datagram and gives it to Alice.
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 37]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   (11) Alice receives datagram.  Sends new packet to Bob.
+
+   (12) SG-A gets second datagram, sees that tunnel is up, and uses it.
+
+   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.
+
+11.2.1 (5) IPsec datagram interception
+
+   At point (5), SG-A intercepts the datagram because this source/
+   destination pair lacks a policy (the non-existent policy state).  SG-
+   A creates a hold policy, and buffers the datagram.  SG-A requests
+   keys from the keying daemon.
+
+11.2.2 (5B) DNS lookup for TXT record
+
+   SG-A's IKE daemon, having looked up the source/destination pair in
+   the connection class list, creates a new Potential OE connection
+   instance.  SG-A starts DNS queries.
+
+11.2.3 (5C) DNS returns TXT record(s)
+
+   DNS returns properly formed TXT delegation records, and SG-A's IKE
+   daemon causes this instance to make a transition from Potential OE
+   connection to Pending OE connection.
+
+   Using the example above, the returned record might contain:
+
+   ---------------------------------------------------------------------
+
+
+   X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
+
+         Figure 7: Example of reverse delegation record for Bob
+
+   ---------------------------------------------------------------------
+
+    with SG-B's IP address and public key listed.
+
+11.2.4 (5D) Initial IKE main mode packet goes out
+
+   Upon entering Pending OE connection, SG-A sends the initial ISAKMP
+   message with proposals.  See Section 4.6.1.
+
+11.2.5 (5E1) Message 2 of phase 1 exchange
+
+   SG-B receives the message.  A new connection instance is created in
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 38]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   the unauthenticated OE peer state.
+
+11.2.6 (5E2) Message 3 of phase 1 exchange
+
+   SG-A sends a Diffie-Hellman exponent.  This is an internal state of
+   the keying daemon.
+
+11.2.7 (5E3) Message 4 of phase 1 exchange
+
+   SG-B responds with a Diffie-Hellman exponent.  This is an internal
+   state of the keying protocol.
+
+11.2.8 (5E4) 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 Section 4.6.1.  This is an
+   internal state of the keying protocol.
+
+11.2.9 (5F1) 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 Section 5.1 for further details.
+
+11.2.10 (5F2) 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 Section 5.2.
+
+11.2.11 (5E5) Responder replies with ID and authentication
+
+   SG-B sends its ID along with authentication material.  This is an
+   internal state for the keying protocol.
+
+11.2.12 (5G) IKE phase 2
+
+11.2.12.1 (5G1) Initiator proposes tunnel
+
+   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.
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 39]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+11.2.12.2 (5H1) Responder determines initiator's authority
+
+   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.
+
+   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.
+
+11.2.12.3 (5H2) DNS replies with TXT record(s)
+
+   The returned key and IP address should match that of SG-A.
+
+11.2.12.4 (5G2) Responder agrees to proposal
+
+   Should additional communication occur between, for instance, Dave and
+   Bob using SG-A and SG-B, a new tunnel (phase 2 SA) would be
+   established.  The phase 1 SA may be reusable.
+
+   SG-A, having successfully keyed the tunnel, now makes a transition
+   from Pending OE connection to Keyed OE connection.
+
+   The responder MUST setup the inbound IPsec SAs before sending its
+   reply.
+
+11.2.12.5 (5G3) Final acknowledgment from initiator
+
+   The initiator agrees with the responder's choice and sets up the
+   tunnel.  The initiator sets up the inbound and outbound IPsec SAs.
+
+   The proper authorization returned with keys prompts SG-B to make a
+   transition to the keyed OE connection state.
+
+   Upon receipt of this message, the responder may now setup the
+   outbound IPsec SAs.
+
+11.2.13 (6) IPsec succeeds, and sets up 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).
+
+11.2.14 (9) SG-B already has tunnel up with G1 and uses it
+
+   At (9), SG-B has already established an SPD entry mapping Bob->Alice
+   via a tunnel, so this tunnel is simply applied.  The datagram is
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 40]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   encrypted to SG-A, decrypted by SG-A and passed to Alice at (10).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 41]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+12. Security considerations
+
+12.1 Configured vs opportunistic tunnels
+
+   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.
+
+   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.
+
+   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 can not
+   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.
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 42]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+12.2 Firewalls versus Opportunistic Tunnels
+
+   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.
+
+12.3 Denial of service
+
+   There are several different forms of denial of service that an
+   implementor should concern themselves 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 43]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+13. IANA Considerations
+
+   There are no known numbers which IANA will need to manage.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 44]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+14. Acknowledgments
+
+   Substantive portions of this document are based upon previous work by
+   Henry Spencer.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 45]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+Normative references
+
+   [1]   Redelmeier, D. and H. Spencer, "Opportunistic Encryption",
+         paper http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/
+         opportunism.spec, May 2001.
+
+   [2]   Defense Advanced Research Projects Agency (DARPA), Information
+         Processing Techniques Office and University of Southern
+         California (USC)/Information Sciences Institute, "Internet
+         Protocol", STD 5, RFC 791, September 1981.
+
+   [3]   Braden, R. and J. Postel, "Requirements for Internet gateways",
+         RFC 1009, June 1987.
+
+   [4]   IAB, IESG, Carpenter, B. and F. Baker, "IAB and IESG Statement
+         on Cryptographic Technology and the Internet", RFC 1984, August
+         1996.
+
+   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [6]   McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management API,
+         Version 2", RFC 2367, July 1998.
+
+   [7]   Kent, S. and R. Atkinson, "Security Architecture for the
+         Internet Protocol", RFC 2401, November 1998.
+
+   [8]   Piper, D., "The Internet IP Security Domain of Interpretation
+         for ISAKMP", RFC 2407, November 1998.
+
+   [9]   Maughan, D., Schneider, M. and M. Schertler, "Internet Security
+         Association and Key Management Protocol (ISAKMP)", RFC 2408,
+         November 1998.
+
+   [10]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
+         RFC 2409, November 1998.
+
+   [11]  Kivinen, T. and M. Kojo, "More MODP Diffie-Hellman groups for
+         IKE", RFC 3526, March 2003.
+
+   [12]  Mockapetris, P., "Domain names - concepts and facilities", STD
+         13, RFC 1034, November 1987.
+
+   [13]  Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [14]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
+         August 1999.
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 46]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+   [15]  Rosenbaum, R., "Using the Domain Name System To Store Arbitrary
+         String Attributes", RFC 1464, May 1993.
+
+   [16]  Eastlake, D., "Domain Name System Security Extensions", RFC
+         2535, March 1999.
+
+   [17]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
+         System (DNS)", RFC 3110, May 2001.
+
+   [18]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
+         Domain Name System (DNS)", RFC 2538, March 1999.
+
+   [19]  Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A.
+         Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
+         2748, January 2000.
+
+   [20]  Srisuresh, P. and M. Holdrege, "IP Network Address Translator
+         (NAT) Terminology and Considerations", RFC 2663, August 1999.
+
+
+Authors' Addresses
+
+   Michael C. Richardson
+   Sandelman Software Works
+   470 Dawson Avenue
+   Ottawa, ON  K1Z 5V7
+   CA
+
+   EMail: mcr@sandelman.ottawa.on.ca
+   URI:   http://www.sandelman.ottawa.on.ca/
+
+
+   D. Hugh Redelmeier
+   Mimosa
+   Toronto, ON
+   CA
+
+   EMail: hugh@mimosa.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 47]
+
+Internet-Draft                opportunistic                     May 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson & Redelmeier    Expires November 19, 2003           [Page 48]
+
diff --git a/doc/draft-richardson-ipsec-rr.txt b/doc/draft-richardson-ipsec-rr.txt
new file mode 100644
index 000000000..7c229b8e1
--- /dev/null
+++ b/doc/draft-richardson-ipsec-rr.txt
@@ -0,0 +1,840 @@
+
+
+IPSECKEY WG                                                M. Richardson
+Internet-Draft                                                       SSW
+Expires: March 4, 2004                                 September 4, 2003
+
+
+           A method for storing IPsec keying material in DNS.
+                     draft-ietf-ipseckey-rr-07.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on March 4, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes a new resource record for DNS.  This record
+   may be used to store public keys for use in IPsec systems.
+
+   This record replaces the functionality of the sub-type #1 of the KEY
+   Resource Record, which has been obsoleted by RFC3445.
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                 [Page 1]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   1.2 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Storage formats  . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.1 IPSECKEY RDATA format  . . . . . . . . . . . . . . . . . . . .  4
+   2.2 RDATA format - precedence  . . . . . . . . . . . . . . . . . .  4
+   2.3 RDATA format - algorithm type  . . . . . . . . . . . . . . . .  4
+   2.4 RDATA format - gateway type  . . . . . . . . . . . . . . . . .  4
+   2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . .  5
+   2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . .  5
+   3.  Presentation formats . . . . . . . . . . . . . . . . . . . . .  7
+   3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . .  7
+   3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   4.1 Active attacks against unsecured IPSECKEY resource records . .  9
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
+   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
+       Normative references . . . . . . . . . . . . . . . . . . . . . 13
+       Non-normative references . . . . . . . . . . . . . . . . . . . 14
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
+       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                 [Page 2]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+1. Introduction
+
+   The type number for the IPSECKEY RR is TBD.
+
+1.1 Overview
+
+   The IPSECKEY resource record (RR) is used to publish a public key
+   that is to be associated with a Domain Name System (DNS) name for use
+   with the IPsec protocol suite.  This can be the  public key of a
+   host, network, or application (in the case of per-port keying).
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC2119 [8].
+
+1.2 Usage Criteria
+
+   An IPSECKEY resource record SHOULD be used in combination with DNSSEC
+   unless some other means of authenticating the IPSECKEY resource
+   record is available.
+
+   It is expected that there will often be multiple IPSECKEY resource
+   records at the same name.  This will be due to the presence of
+   multiple gateways and the need to rollover keys.
+
+   This resource record is class independent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                 [Page 3]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+2. Storage formats
+
+2.1 IPSECKEY RDATA format
+
+   The RDATA for an IPSECKEY RR consists of a precedence value, a public
+   key, algorithm type, and an optional gateway address.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  precedence   | gateway type  |  algorithm  |     gateway     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
+      ~                            gateway                            ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               /
+      /                          public key                           /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+
+2.2 RDATA format - precedence
+
+   This is an 8-bit precedence for this record.  This is interpreted in
+   the same way as the PREFERENCE field described in section 3.3.9 of
+   RFC1035 [2].
+
+   Gateways listed in IPSECKEY records with  lower precedence are to be
+   attempted first.  Where there is a tie in precedence, the order
+   should be non-deterministic.
+
+2.3 RDATA format - algorithm type
+
+   The algorithm type field identifies the public key's cryptographic
+   algorithm and determines the format of the public key field.
+
+   A value of 0 indicates that no key is present.
+
+   The following values are defined:
+
+   1  A DSA key is present, in the format defined in RFC2536 [11]
+
+   2  A RSA key is present, in the format defined in RFC3110 [12]
+
+
+2.4 RDATA format - gateway type
+
+   The gateway type field indicates the format of the information that
+   is stored in the gateway field.
+
+
+
+Richardson                Expires March 4, 2004                 [Page 4]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+   The following values are defined:
+
+   0  No gateway is present
+
+   1  A 4-byte IPv4 address is present
+
+   2  A 16-byte IPv6 address is present
+
+   3  A wire-encoded domain name is present.  The wire-encoded format is
+      self-describing, so the length is implicit.  The domain name MUST
+      NOT be compressed.
+
+
+2.5 RDATA format - gateway
+
+   The gateway field indicates a gateway to which an IPsec tunnel may be
+   created in order to reach the entity named by this resource record.
+
+   There are three formats:
+
+   A 32-bit IPv4 address is present in the gateway field.  The data
+   portion is an IPv4 address as described in section 3.4.1 of RFC1035
+   [2].  This is a 32-bit number in network byte order.
+
+   A 128-bit IPv6 address is present in the gateway field.  The data
+   portion is an IPv6 address as described in section 2.2 of RFC1886
+   [7].  This is a 128-bit number in network byte order.
+
+   The gateway field is a normal wire-encoded domain name, as described
+   in section 3.3 of RFC1035 [2].  Compression MUST NOT be used.
+
+2.6 RDATA format - public keys
+
+   Both of the public key types defined in this document (RSA and DSA)
+   inherit their public key formats from the corresponding KEY RR
+   formats.  Specifically, the public key field contains the algorithm-
+   specific portion of the KEY RR RDATA, which is all of the KEY RR DATA
+   after the first four octets.  This is the same portion of the KEY RR
+   that must be specified by documents that define a DNSSEC algorithm.
+   Those documents also specify a message digest to be used for
+   generation of SIG RRs; that specification is not relevant for
+   IPSECKEY RR.
+
+   Future algorithms, if they are to be used by both DNSSEC (in the KEY
+   RR) and IPSECKEY, are likely to use the same public key encodings in
+   both records.  Unless otherwise specified, the IPSECKEY public key
+   field will contain the algorithm-specific portion of the KEY RR RDATA
+   for the corresponding algorithm.  The algorithm must still be
+
+
+
+Richardson                Expires March 4, 2004                 [Page 5]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+   designated for use by IPSECKEY, and an IPSECKEY algorithm type number
+   (which might be different than the DNSSEC algorithm number) must be
+   assigned to it.
+
+   The DSA key format is defined in RFC2536 [11]
+
+   The RSA key format is defined in RFC3110 [12], with the following
+   changes:
+
+   The earlier definition of RSA/MD5 in RFC2065 limited the exponent and
+   modulus to 2552 bits in length.  RFC3110 extended that limit to 4096
+   bits for RSA/SHA1 keys.  The IPSECKEY RR imposes no length limit on
+   RSA public keys, other than the 65535 octet limit imposed by the two-
+   octet length encoding.  This length extension is applicable only to
+   IPSECKEY and not to KEY RRs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                 [Page 6]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+3. Presentation formats
+
+3.1 Representation of IPSECKEY RRs
+
+   IPSECKEY RRs may appear in a zone data master file.  The precedence,
+   gateway type and algorithm and gateway fields are REQUIRED.  The
+   base64 encoded public key block is OPTIONAL; if not present, then the
+   public key field of the resource record MUST be construed as being
+   zero octets in length.
+
+   The algorithm field is an unsigned integer.  No mnemonics are
+   defined.
+
+   If no gateway is to be indicated, then the gateway type field MUST be
+   zero, and the gateway field MUST be "."
+
+   The Public Key field is represented as a Base64 encoding of the
+   Public Key.  Whitespace is allowed within the Base64 text.  For a
+   definition of Base64 encoding, see RFC1521 [3] Section 5.2.
+
+   The general presentation for the record as as follows:
+
+   IN     IPSECKEY ( precedence gateway-type algorithm
+                     gateway base64-encoded-public-key )
+
+
+3.2 Examples
+
+   An example of a node 192.0.2.38 that will accept IPsec tunnels on its
+   own behalf.
+
+   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
+                    192.0.2.38
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+   An example of a node, 192.0.2.38 that has published its key only.
+
+   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
+                    .
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+   An example of a node, 192.0.2.38 that has delegated authority to the
+   node 192.0.2.3.
+
+   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
+                    192.0.2.3
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+
+
+
+Richardson                Expires March 4, 2004                 [Page 7]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+   An example of a node, 192.0.1.38 that has delegated authority to the
+   node with the identity "mygateway.example.com".
+
+   38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
+                    mygateway.example.com.
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+   An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has
+   delegated authority to the node 2001:0DB8:c000:0200:2::1
+
+   $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int.
+   0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
+                    2001:0DB8:0:8002::2000:1
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                 [Page 8]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+4. Security Considerations
+
+   This entire memo pertains to the provision of public keying material
+   for use by key management protocols such as ISAKMP/IKE (RFC2407) [9].
+
+   The IPSECKEY resource record contains information that SHOULD be
+   communicated to the end client in an integral fashion - i.e.  free
+   from modification.  The form of this channel is up to the consumer of
+   the data - there must be a trust relationship between the end
+   consumer of this resource record and the server.  This relationship
+   may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to
+   another secure source, a secure local channel on the host, or some
+   combination of the above.
+
+   The keying material provided by the IPSECKEY resource record is not
+   sensitive to passive attacks.  The keying material may be freely
+   disclosed to any party without any impact on the security properties
+   of the resulting IPsec session: IPsec and IKE provide for defense
+   against both active and passive attacks.
+
+   Any user of this resource record MUST carefully document their trust
+   model, and why the trust model of DNSSEC is appropriate, if that is
+   the secure channel used.
+
+4.1 Active attacks against unsecured IPSECKEY resource records
+
+   This section deals with active attacks against the DNS.  These
+   attacks require that DNS requests and responses be intercepted and
+   changed.  DNSSEC is designed to defend against attacks of this kind.
+
+   The first kind of active attack is when the attacker replaces the
+   keying material with either a key under its control or with garbage.
+
+   If the attacker is not able to mount a subsequent man-in-the-middle
+   attack on the IKE negotiation after replacing the public key, then
+   this will result in a denial of service, as the authenticator used by
+   IKE would fail.
+
+   If the attacker is able to both to mount active attacks against DNS
+   and is also in a position to perform a man-in-the-middle attack on
+   IKE and IPsec negotiations, then the attacker will be in a position
+   to compromise the resulting IPsec channel.  Note that an attacker
+   must be able to perform active DNS attacks on both sides of the IKE
+   negotiation in order for this to succeed.
+
+   The second kind of active attack is one in which the attacker
+   replaces the the gateway address to point to a node under the
+   attacker's control.  The attacker can then either replace the public
+
+
+
+Richardson                Expires March 4, 2004                 [Page 9]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+   key or remove it, thus providing an IPSECKEY record of its own to
+   match the gateway address.
+
+   This later form creates a simple man-in-the-middle since the attacker
+   can then create a second tunnel to the real destination.  Note that,
+   as before, this requires that the attacker also mount an active
+   attack against the responder.
+
+   Note that the man-in-the-middle can not just forward cleartext
+   packets to the original destination.  While the destination may be
+   willing to speak in the clear, replying to the original sender, the
+   sender will have already created a policy expecting ciphertext.
+   Thus, the attacker will need to intercept traffic from both sides.
+   In some cases, the attacker may be able to accomplish the full
+   intercept by use of Network Addresss/Port Translation (NAT/NAPT)
+   technology.
+
+   Note that the danger here only applies to cases where the gateway
+   field of the IPSECKEY RR indicates a different entity than the owner
+   name of the IPSECKEY RR.  In cases where the end-to-end integrity of
+   the IPSECKEY RR is suspect, the end client MUST restrict its use of
+   the IPSECKEY RR to cases where the RR owner name matches the content
+   of the gateway field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                [Page 10]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+5. IANA Considerations
+
+   This document updates the IANA Registry for DNS Resource Record Types
+   by assigning type X to the IPSECKEY record.
+
+   This document creates an IANA registry for the algorithm type field.
+
+   Values 0, 1 and 2 are defined in Section 2.3.  Algorithm numbers 3
+   through 255 can be assigned by IETF Consensus (see RFC2434 [6]).
+
+   This document creates an IANA registry for the gateway type field.
+
+   Values 0, 1, 2 and 3 are defined in Section 2.4.  Algorithm numbers 4
+   through 255 can be assigned by Standards Action (see RFC2434 [6]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                [Page 11]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+6. Acknowledgments
+
+   My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
+   Austein, and Olafur Gurmundsson who reviewed this document carefully.
+   Additional thanks to Olafur Gurmundsson for a reference
+   implementation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                [Page 12]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+Normative references
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
+        Extensions) Part One: Mechanisms for Specifying and Describing
+        the Format of Internet Message Bodies", RFC 1521, September
+        1993.
+
+   [4]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [5]  Eastlake, D. and C. Kaufman, "Domain Name System Security
+        Extensions", RFC 2065, January 1997.
+
+   [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                [Page 13]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+Non-normative references
+
+   [7]   Thomson, S. and C. Huitema, "DNS Extensions to support IP
+         version 6", RFC 1886, December 1995.
+
+   [8]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [9]   Piper, D., "The Internet IP Security Domain of Interpretation
+         for ISAKMP", RFC 2407, November 1998.
+
+   [10]  Eastlake, D., "Domain Name System Security Extensions", RFC
+         2535, March 1999.
+
+   [11]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
+         (DNS)", RFC 2536, March 1999.
+
+   [12]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
+         System (DNS)", RFC 3110, May 2001.
+
+   [13]  Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
+         Record (RR)", RFC 3445, December 2002.
+
+
+Author's Address
+
+   Michael C. Richardson
+   Sandelman Software Works
+   470 Dawson Avenue
+   Ottawa, ON  K1Z 5V7
+   CA
+
+   EMail: mcr@sandelman.ottawa.on.ca
+   URI:   http://www.sandelman.ottawa.on.ca/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                [Page 14]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                [Page 15]
+
diff --git a/doc/draft-spencer-ipsec-ike-implementation.nr b/doc/draft-spencer-ipsec-ike-implementation.nr
new file mode 100644
index 000000000..5b5776e22
--- /dev/null
+++ b/doc/draft-spencer-ipsec-ike-implementation.nr
@@ -0,0 +1,1203 @@
+.\" date, expiry date, copyright year, and revision
+.DA "26 Feb 2002"
+.ds e "26 Aug 2002
+.ds c 2002
+.ds r 02
+.\" boilerplate
+.pl 10i
+.nr PL 10i
+.po 0
+.nr PO 0
+.ll 7.2i
+.nr LL 7.2i
+.lt 7.2i
+.nr LT 7.2i
+.hy 0
+.nr HY 0
+.ad l
+.nr PD 1v
+.\" macros for paragraph, section header, reference, TOC
+.de P
+.br
+.LP
+.in 3
+..
+.de H
+.br
+.ne 5
+.LP
+.in 0
+..
+.de R
+.IP "   [\\$1]" 14
+..
+.de T
+.ie \\$1=1 \{\
+.nf
+.ta \n(LLu-3nR
+.\}
+.el \{\
+.fi
+.\}
+..
+.de S
+.ie '\\$1'' \\$2 \a \\$3
+.el \\$1. \\$2 \a \\$3
+..
+.\" headers/footers
+.ds LH "Internet Draft
+.ds CH "IKE Implementation Issues
+.ds RH "\*(DY
+.ds LF "Spencer & Redelmeier
+.ds CF "
+.ds RF "[Page %]
+.\" and let's get started
+.RT
+.nf
+.tl 'Network Working Group''Henry Spencer'
+.tl 'Internet Draft''SP Systems'
+.tl 'Expires: \*e''D. Hugh Redelmeier'
+.tl '''Mimosa Systems'
+.tl '''\*(DY'
+.sp
+.ce 99
+IKE Implementation Issues
+<draft-spencer-ipsec-ike-implementation-\*r.txt>
+.ce 0
+.H
+Status of this Memo
+.P
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC2026.
+.P
+(If approved as an Informational RFC...)
+This memo provides information for the Internet community.
+This memo does not specify an Internet standard of any kind.
+.P
+Distribution of this memo is unlimited.
+.P
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.
+Note that
+other groups may also distribute working documents as Internet-Drafts.
+.P
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time.
+It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
+.P
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt.
+.P
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+.P
+This Internet-Draft will expire on \*e.
+.H
+Copyright Notice
+.P
+Copyright (C) The Internet Society \*c.  All Rights Reserved.
+.bp
+.H
+Table of Contents
+.P
+.T 1
+.S "1" "Introduction" "3"
+.S "2" "Lower-level Background and Notes" "4"
+.S "2.1" "Packet Handling" "4"
+.S "2.2" "Ciphers" "5"
+.S "2.3" "Interfaces" "5"
+.S "3" "IKE Infrastructural Issues" "5"
+.S "3.1" "Continuous Channel" "5"
+.S "3.2" "Retransmission" "5"
+.S "3.3" "Replay Prevention" "6"
+.S "4" "Basic Keying and Rekeying" "7"
+.S "4.1" "When to Create SAs" "7"
+.S "4.2" "When to Rekey" "8"
+.S "4.3" "Choosing an SA" "9"
+.S "4.4" "Why to Rekey" "9"
+.S "4.5" "Rekeying ISAKMP SAs" "10"
+.S "4.6" "Bulk Negotiation" "10"
+.S "5" "Deletions, Teardowns, Crashes" "11"
+.S "5.1" "Deletions" "11"
+.S "5.2" "Teardowns and Shutdowns" "12"
+.S "5.3" "Crashes" "13"
+.S "5.4" "Network Partitions" "13"
+.S "5.5" "Unknown SAs" "14"
+.S "6" "Misc. IKE Issues" "16"
+.S "6.1" "Groups 1 and 5" "16"
+.S "6.2" "To PFS Or Not To PFS" "16"
+.S "6.3" "Debugging Tools, Lack Thereof" "16"
+.S "6.4" "Terminology, Vagueness Thereof" "17"
+.S "6.5" "A Question of Identity" "17"
+.S "6.6" "Opportunistic Encryption" "17"
+.S "6.7" "Authentication and RSA Keys" "17"
+.S "6.8" "Misc. Snags" "18"
+.S "7" "Security Considerations" "19"
+.S "8" "References" "19"
+.S "" "Authors' Addresses" "20"
+.S "" "Full Copyright Statement" "21"
+.T 0
+.bp
+.H
+Abstract
+.P
+The current IPsec specifications for key exchange and connection management,
+RFCs 2408 [ISAKMP] and 2409 [IKE],
+leave many aspects of connection management unspecified,
+most prominently rekeying practices.
+Pending clarifications in future revisions of the specifications,
+this document sets down some successful experiences,
+to minimize the extent to which new implementors have to rely
+on unwritten folklore.
+.P
+The Linux FreeS/WAN implementation of IPsec interoperates
+with almost every other IPsec implementation.
+This document describes how the FreeS/WAN project has resolved
+some of the gaps in the IPsec specifications
+(and plans to resolve some others),
+and what difficulties have been encountered,
+in hopes that this generally-successful experience
+might be informative to new implementors.
+.P
+This is offered as an Informational RFC.
+.P
+This -\*r revision mainly:
+discusses ISAKMP SA expiry during IPsec-SA rekeying (4.5),
+revises the discussion of bidirectional Deletes (5.1),
+suggests remembering the parameters of successful negotiations
+for later use (4.2, 5.3),
+notes an unsuccessful negotiation from the other end as a hint of a possibly
+broken connection (5.5),
+and adds sections on network partitions (5.4),
+authentication methods and the subtleties of RSA public keys (6.7),
+and miscellaneous interoperability concerns (6.8).
+.H
+1. Introduction
+.P
+The current IPsec specifications for key exchange and connection management,
+RFCs 2408 [ISAKMP] and 2409 [IKE],
+leave many aspects of connection management unspecified,
+most prominently rekeying practices.
+This is a cryptic puzzle which
+each group of implementors has to struggle with,
+and differences in how the ambiguities and gaps are resolved are
+potentially a fruitful source of interoperability problems.
+We can hope that future revisions of the specifications will clear this up.
+Meanwhile, it seems useful to set down some successful experiences,
+to minimize the extent to which new implementors have to rely
+on unwritten folklore.
+.P
+The Linux FreeS/WAN implementation of IPsec interoperates
+with almost every other IPsec implementation,
+and because of its free nature,
+it also sees some use as a reference implementation by other implementors.
+The high degree of interoperability is noteworthy
+given its organizers' strong minimalist bias,
+which has caused them to implement only
+a small subset of the full glory of IPsec.
+This document describes how the FreeS/WAN project has resolved
+some of the gaps in the IPsec specifications
+(and plans to resolve some others),
+and what difficulties have been encountered,
+in hopes that this generally-successful experience
+might be informative to new implementors.
+.P
+One small caution about applicability:
+this experience may not be relevant
+to severely resource-constrained implementations.
+FreeS/WAN's target environment is previous-generation PCs,
+now available at trivial cost (often,
+within an organization, at no cost),
+which have quite impressive CPU power and memory by the standards
+of only a few years ago.
+Some of the approaches discussed here may be inapplicable to
+implementations with severe external constraints which prevent them
+from taking advantage of modern hardware technology.
+.H
+2. Lower-level Background and Notes
+.H
+2.1. Packet Handling
+.P
+FreeS/WAN implements ESP [ESP] and AH [AH] straightforwardly,
+although AH sees little use among our users.
+Our ESP/AH implementation cannot currently handle packets
+with IP options;
+somewhat surprisingly, this has caused little difficulty.
+We insist on encryption and do not support authentication-only
+connections, and this has not caused significant difficulty either.
+.P
+MTU and fragmentation issues, by contrast, have been a constant headache.
+We will not describe the details of our current approach to them,
+because it still needs work.
+One difficulty we have encountered is that many combinations of
+packet source and packet destination
+apparently cannot cope with an "interior minimum" in the path MTU,
+e.g. where an IPsec tunnel intervenes and its headers reduce the MTU
+for an intermediate link.
+This is particularly prevalent when using common PC software to
+connect to large well-known web sites;
+we think it is largely due to
+misconfigured firewalls which do not pass ICMP
+Fragmentation Required messages.
+The only solution we have yet found is to lie about the MTU of the tunnel,
+accepting the (undesirable) fragmentation of the ESP packets
+for the sake of preserving connectivity.
+.P
+We currently zero out the TOS field of ESP packets,
+rather than copying it from the inner header,
+on the grounds that it lends itself too well to traffic analysis
+and covert channels.
+We provide an option to restore RFC 2401 [IPSEC] copying behavior,
+but this appears to see little use.
+.H
+2.2. Ciphers
+.P
+We initially implemented both DES [DES] and 3DES [CIPHERS] for both
+IKE and ESP,
+but after the Deep Crack effort [CRACK] demonstrated its inherent insecurity,
+we dropped support for DES.
+Somewhat surprisingly,
+our insistence on 3DES has caused almost no interoperability problems,
+despite DES being officially mandatory.
+A very few other systems either do not support 3DES or support it only
+as an optional upgrade,
+which inconveniences a few would-be users.
+There have also been one or two cases of systems
+which don't quite seem to know the difference!
+.P
+See also section 6.1 for a consequence of our insistence on 3DES.
+.H
+2.3. Interfaces
+.P
+We currently employ PF_KEY version 2 [PFKEY],
+plus various non-standard extensions,
+as our interface between keying and ESP.
+This has not proven entirely satisfactory.
+Our feeling now is that keying issues and policy issues
+do not really lend
+themselves to the clean separation that PF_KEY envisions.
+.H
+3. IKE Infrastructural Issues
+.P
+A number of problems in IPsec connection management become easier if
+some attention is first paid to providing an infrastructure
+to support solving them.
+.H
+3.1. Continuous Channel
+.P
+FreeS/WAN uses an approximation to the "continuous channel" model,
+in which ISAKMP SAs are maintained between IKEs
+so long as any IPsec SAs are open between the two systems.
+The resource consumption of this is minor:
+the only substantial overhead is occasional rekeying.
+IPsec SA management becomes significantly simpler if there is always
+a channel for transmission of control messages.
+We suggest (although we do not yet fully implement this) that
+inability to maintain (e.g., to rekey) this control path
+should be grounds for tearing down the IPsec SAs as well.
+.P
+As a corollary of this,
+there is one and only one ISAKMP SA maintained between a pair of IKEs
+(although see sections 5.3 and 6.5 for minor complications).
+.H
+3.2. Retransmission
+.P
+The unreliable nature of UDP transmission is a nuisance.
+IKE implementations should always be prepared to retransmit the most recent
+message they sent on an ISAKMP SA,
+since there is some possibility that the other end did not get it.
+This means, in particular,
+that the system sending the supposedly-last message of an exchange
+cannot relax and assume that the exchange is complete,
+at least not until a significant timeout has elapsed.
+.P
+Systems must also retain information about the message most recently received
+in an exchange,
+so that a duplicate of it can be detected
+(and possibly interpreted as a NACK for the response).
+.P
+The retransmission rules FreeS/WAN follows are:
+(1) if a reply is expected, retransmit only if it does not appear
+before a timeout;
+and (2) if a reply is not expected (last message of the exchange),
+retransmit only on receiving a retransmission of the previous message.
+Notably, in case (1) we do NOT retransmit on receiving a retransmission,
+which avoids possible congestion problems arising from packet duplication,
+at the price of slowing response to packet loss.
+The timeout for case (1) is 10 seconds for the first retry,
+20 seconds for the second, and 40 seconds for all subsequent
+retries (normally only one,
+except when
+configuration settings call for persistence and the message is
+the first message of Main Mode with a new peer).
+These retransmission rules have been entirely successful.
+.P
+(Michael Thomas of Cisco has pointed out that the retry timeouts should
+include some random jitter, to de-synchronize hosts which are
+initially synchronized by, e.g., a power outage.
+We already jitter our rekeying times,
+as noted in section 4.2,
+but that does not help with initial startup.
+We're implementing jittered retries,
+but cannot yet report on experience with this.)
+.P
+There is a deeper problem, of course, when an entire "exchange" consists
+of a single message,
+e.g. the ISAKMP Informational Exchange.
+Then there is no way to decide whether or when a retransmission is
+warranted at all.
+This seems like poor design, to put it mildly
+(and there is now talk of fixing it).
+We have no experience in dealing with this problem at this time,
+although it is part of the reason why we have delayed implementing
+Notification messages.
+.H
+3.3. Replay Prevention
+.P
+The unsequenced nature of UDP transmission is also troublesome,
+because it means that higher levels must consider the possibility
+of replay attacks.
+FreeS/WAN takes the position that systematically eliminating this
+possibility at a low level is strongly preferable to forcing careful
+consideration of possible impacts at every step of an exchange.
+RFC 2408 [ISAKMP] section 3.1 states that the Message ID of an
+ISAKMP message must be "unique".
+FreeS/WAN interprets this literally,
+as forbidding duplication of Message IDs
+within the set of all messages sent via a single ISAKMP SA.
+.P
+This requires remembering all Message IDs until the ISAKMP SA is
+superseded by rekeying,
+but that is not costly (four bytes per sent or received message),
+and it ELIMINATES replay attacks from consideration;
+we believe this investment of resources is well worthwhile.
+If the resource consumption becomes excessive\(emin our experience
+it has not\(emthe ISAKMP SA can be rekeyed early to collect the garbage.
+.P
+There is theoretically an interoperability problem when talking to
+implementations which interpret "unique" more loosely
+and may re-use Message IDs,
+but it has not been encountered in practice.
+This approach appears to be completely interoperable.
+.P
+The proposal by
+Andrew Krywaniuk [REPLAY],
+which advocates turning the Message ID into an anti-replay counter,
+would achieve the same goal without the minor per-message memory overhead.
+This may be preferable,
+although it means an actual protocol change and more study is needed.
+.H
+4. Basic Keying and Rekeying
+.H
+4.1. When to Create SAs
+.P
+As Tim Jenkins [REKEY] pointed out,
+there is a potential race condition in Quick Mode:
+a fast lightly-loaded Initiator might start using IPsec SAs very
+shortly after sending QM3 (the third and last message of Quick Mode),
+while a slow heavily-loaded Responder might
+not be ready to receive them until after spending
+a significant amount of time creating its inbound SAs.
+The problem is even worse if QM3 gets delayed or lost.
+.P
+FreeS/WAN's approach to this is what Jenkins called "Responder Pre-Setup":
+the Responder creates its inbound IPsec SAs before it sends QM2,
+so they are always ready and waiting
+when the Initiator sends QM3 and begins sending traffic.
+This approach is simple and reliable,
+and in our experience it interoperates with everybody.
+(There is potentially still a problem if FreeS/WAN is the Initiator
+and the Responder does not use Responder Pre-Setup,
+but no such problems have been seen.)
+The only real weakness of Responder Pre-Setup
+is the possibility of replay attacks,
+which we have eliminated by other means (see section 3.3).
+.P
+With this approach, the Commit Bit is useless,
+and we ignore it.
+In fact, until quite recently we discarded any IKE message containing it,
+and this caused surprisingly few interoperability problems;
+apparently it is not widely used.
+We have recently been persuaded that simply ignoring it is preferable;
+preliminary experience with this indicates that the result is successful
+interoperation with implementations which set it.
+.H
+4.2. When to Rekey
+.P
+To preserve connectivity for user traffic,
+rekeying of a connection
+(that is, creation of new IPsec SAs to supersede the current ones)
+must begin before its current IPsec SAs expire.
+Preferably one end should predictably start rekeying negotiations first,
+to avoid the extra overhead of two simultaneous negotiations,
+although either end should be prepared to rekey if the other does not.
+There is also a problem with "convoys" of keying negotiations:
+for example, a "hub" gateway with many IPsec connections
+can be inundated with rekeying negotiations
+exactly one connection-expiry time after it reboots,
+and the massive overload this induces tends to make this
+situation self-perpetuating,
+so it recurs regularly.
+(Convoys can also evolve gradually from initially-unsynchronized negotiations.)
+.P
+FreeS/WAN has the concept of a "rekeying margin", measured in seconds.
+If FreeS/WAN was the Initiator for the previous rekeying
+(or the startup, if none) of the connection,
+it nominally starts rekeying negotiations at expiry time
+minus one rekeying margin.
+Some random jitter is added to break up convoys:
+rather than starting rekeying exactly at minus one margin,
+it starts at a random time between minus one margin
+and minus two margins.
+(The randomness here need not be cryptographic in quality,
+so long as it varies over time and between hosts.
+We use an ordinary PRNG seeded with a few bytes from a cryptographic
+randomness source.
+The seeding mostly just ensures that the PRNG sequence is different
+for different hosts, even if they start up simultaneously.)
+.P
+If FreeS/WAN was the Responder for the previous rekeying/startup,
+and nothing has been heard from the previous Initiator
+at expiry time minus one-half the rekeying margin,
+FreeS/WAN will initiate rekeying negotiations.
+No jitter is applied;
+we now believe that it should be jittered,
+say between minus one-half margin and minus one-quarter margin.
+.P
+Having the Initiator lead the way is an obvious way of deciding
+who should speak first,
+since there is already an Initiator/Responder asymmetry in the connection.
+Moreover, our experience has been that Initiator lead gives a significantly
+higher probability of successful negotiation!
+The negotiation process itself is asymmetric,
+because the Initiator must make a few specific proposals which the Responder
+can only accept or reject,
+so the Initiator must try to guess where its "acceptable" region
+(in parameter space)
+might overlap with the Responder's.
+We have seen situations where negotiations would succeed or fail
+depending on which end initiated them,
+because one end was making better guesses.
+Given an existing connection,
+we KNOW that the previous Initiator WAS able to initiate a successful
+negotiation,
+so it should (if at all possible) take the lead again.
+Also, the Responder should remember the Initiator's successful proposal,
+and start from that
+rather than from his own default proposals if he must take the lead;
+we don't currently implement this completely but plan to.
+.P
+FreeS/WAN defaults the rekeying margin to 9 minutes,
+although this can be changed by configuration.
+There is also
+a configuration option to alter the permissible range of jitter.
+The defaults were chosen somewhat arbitrarily,
+but they work extremely well
+and the configuration options are rarely used.
+.H
+4.3. Choosing an SA
+.P
+Once rekeying has occurred,
+both old and new IPsec SAs for the connection exist,
+at least momentarily.
+FreeS/WAN accepts incoming traffic
+on either old or new inbound SAs,
+but sends outgoing traffic only on the new outbound ones.
+This approach appears to be significantly more robust than
+using the old ones until they expire,
+notably in cases where renegotiation has occurred because something has
+gone wrong on the other end.
+It avoids having to pay meticulous attention to the state of the other end,
+state which is difficult to learn reliably given the limitations of IKE.
+.P
+This approach has interoperated successfully with ALMOST all other
+implementations.
+The only (well-characterized) problem cases have been implementations
+which rely on receiving a Delete message for the old SAs to tell them
+to switch over to the new ones.
+Since delivery of Delete is unreliable,
+and support for Delete is optional,
+this reliance seems like a serious mistake.
+This is all the more true because Delete
+announces that the deletion has
+already occurred [ISAKMP, section 3.15], not that it is about to occur,
+so packets already in transit in the other direction could be lost.
+Delete should be used for resource cleanup, not for switchover control.
+(These matters are discussed further in section 5.)
+.H
+4.4. Why to Rekey
+.P
+FreeS/WAN currently implements only time-based expiry (life in seconds),
+although we are working toward
+supporting volume-based expiry (life in kilobytes) as well.
+The lack of volume-based expiry has not been an interoperability
+problem so far.
+.P
+Volume-based expiry does add some minor complications.
+In particular, it makes explicit Delete of now-disused SAs more important,
+because once an SA stops being used,
+it might not expire on its own.
+We believe this lacks robustness and is generally unwise,
+especially given the lack of a reliable Delete,
+and expect to use volume-based expiry only as a supplement
+to time-based expiry.
+However, Delete support (see section 5) does seem advisable
+for use with volume-based expiry.
+.P
+We do not believe that volume-based expiry alters the desirability
+of switching immediately to the new SAs after rekeying.
+Rekeying margins are normally a small fraction of the total life of an SA,
+so we feel there is no great need to "use it all up".
+.H
+4.5. Rekeying ISAKMP SAs
+.P
+The above discussion has focused on rekeying for IPsec SAs,
+but FreeS/WAN applies the same approaches to rekeying for ISAKMP SAs,
+with similar success.
+.P
+One issue which we have noticed, but not explicitly dealt with,
+is that difficulties may ensue if an IPsec-SA rekeying negotiation
+is in progress at the time when the relevant ISAKMP SA gets rekeyed.
+The IKE specification [IKE] hints, but does not actually say,
+that a Quick Mode negotiation should remain on a single ISAKMP SA throughout.
+.P
+A reasonable rekeying margin will generally
+prevent the old ISAKMP SA from actually expiring during a negotiation.
+Some attention may be needed to prevent in-progress negotiations from
+being switched to the new ISAKMP SA.
+Any attempt at pre-expiry deletion of the ISAKMP SA must be postponed
+until after such dangling negotiations are completed,
+and there should be enough delay between ISAKMP-SA rekeying and a
+deletion attempt to (more or less)
+ensure that there are no negotiation-starting packets still in transit
+from before the rekeying.
+.P
+At present, FreeS/WAN does none of this,
+and we don't KNOW of any resulting trouble.
+With normal lifetimes, the problem should be uncommon,
+and we speculate that an occasional disrupted negotiation simply gets retried.
+.H
+4.6. Bulk Negotiation
+.P
+Quick Mode nominally provides for negotiating possibly-large numbers of
+similar but unrelated IPsec SAs simultaneously
+[IKE, section 9].
+Nobody appears to do this.
+FreeS/WAN does not support it, and its absence has caused no problems.
+.H
+5. Deletions, Teardowns, Crashes
+.P
+FreeS/WAN currently ignores all Notifications and Deletes,
+and never generates them.
+This has caused little difficulty in interoperability,
+which shouldn't be surprising (since Notification and Delete support is
+officially entirely optional) but does seem to surprise some people.
+Nevertheless, we do plan some changes to this approach
+based on past experience.
+.H
+5.1. Deletions
+.P
+As hinted at above,
+we plan to implement Delete support, done as follows.
+Shortly after rekeying of IPsec SAs,
+the Responder issues a Delete for its old inbound SAs
+(but does not actually delete them yet).
+The Responder initiates this because the Initiator started using the
+new SAs on sending QM3, while the Responder started using them only
+on (or somewhat after) receiving QM3,
+so there is less chance of old-SA packets still being in transit from
+the Initiator.
+The Initiator issues an unsolicited Delete only if it does not hear one
+from the Responder after a longer delay.
+.P
+Either party, on receiving a Delete
+for one or more of the old outbound SAs of a connection,
+deletes ALL the connection's SAs,
+and acknowledges with a Delete for the old inbound SAs.
+A Delete for nonexistent SAs
+(e.g., SAs which have already been expired or deleted) is ignored.
+There is no retransmission of unacknowledged Deletes.
+.P
+In the normal case,
+with prompt reliable transmission (except possibly for loss of the
+Responder's initial Delete)
+and conforming implementations
+on both ends, this results in three Deletes being transmitted,
+resembling the classic three-way handshake.
+Loss of a Delete after the first, or multiple losses,
+will cause the SAs not to be deleted on at least one end.
+It appears difficult to do much better without at least
+a distinction between request and acknowledgement.
+.P
+RFC 2409 section 9 "strongly suggests" that there be no response to
+informational messages such as Deletes,
+but the only rationale offered is prevention of infinite loops
+endlessly exchanging "I don't understand you" informationals.
+Since Deletes cannot lead to such a loop
+(and in any case, the nonexistent-SA rule prevents more than one
+acknowledgement for the same connection),
+we believe this recommendation is inapplicable here.
+.P
+As noted in section 4.3, these Deletes are intended for
+resource cleanup, not to control switching between SAs.
+But we expect that they will improve interoperability
+with some broken implementations.
+.P
+We believe strongly that connections need to be considered as a whole,
+rather than treating each SA as an independent entity.
+We will issue Deletes only for the full set of inbound SAs of
+a connection,
+and will treat a Delete for any outbound SA as equivalent to deletion
+of all the outbound SAs for the associated connection.
+.P
+The above is phrased in terms of IPsec SAs,
+but essentially the same approach can be applied to ISAKMP SAs
+(the Deletes for the old ISAKMP SA should be sent via the new one).
+.H
+5.2. Teardowns and Shutdowns
+.P
+When a connection is not intended to be up permanently,
+there is a need to coordinate teardown,
+so that both ends are aware that the connection is down.
+This is both for recovery of resources,
+and to avoid routing packets through
+dangling SAs which can no longer deliver them.
+.P
+Connection teardown will use the same bidirectional exchange of Deletes
+as discussed in section 5.1:
+a Delete received for current IPsec SAs (not yet obsoleted by rekeying)
+indicates that the other host wishes to tear down the associated connection.
+.P
+A Delete received for a current ISAKMP SA indicates that the other host
+wishes to tear down not only the ISAKMP SA but also all IPsec SAs
+currently under the supervision of that ISAKMP SA.
+The 5.1 bidirectional exchange might seem impossible in this case,
+since reception of an ISAKMP-SA Delete indicates that the other end
+will ignore further traffic on that ISAKMP SA.
+We suggest using the same tactic discussed in 5.1 for IPsec SAs:
+the first Delete is sent without actually doing the deletion,
+and the response to receiving a Delete is to do the deletion and reply
+with another Delete.
+If there is no response to the first Delete,
+retry a small number of times and then give up and do the deletion;
+apart from being robust against packet loss,
+this also maximizes the probability that an implementation which does
+not do the bidirectional Delete will receive at least one of the Deletes.
+.P
+When a host with current connections knows that it is about to shut down,
+it will issue Deletes for all SAs involved (both IPsec and ISAKMP),
+advising its peers (as per the meaning of Delete [ISAKMP, section 3.15])
+that the SAs have become useless.
+It will ignore attempts at rekeying or connection startup thereafter,
+until it shuts down.
+.P
+It would be better to have a Final-Contact notification,
+analogous to Initial-Contact but indicating that no new negotiations
+should be attempted until further notice.
+Initial-Contact actually could be used for shutdown notification (!),
+but in networks where connections are intended to exist permanently,
+it seems likely to provoke unwanted attempts
+to renegotiate the lost connections.
+.H
+5.3. Crashes
+.P
+Systems sometimes crash.
+Coping with the resulting loss of information is easily the most
+difficult problem we have found in implementing robust IPsec systems.
+.P
+When connections are intended to be permanent,
+it is simple to specify renegotiation on reboot.
+With our approach to SA selection (see section 4.3),
+this handles such cases robustly and well.
+We do have to tell users that BOTH hosts should be set this way.
+In cases where crashes are synchronized (e.g. by power interruptions),
+this may result in simultaneous negotiations at reboot.
+We currently allow both negotiations to proceed to completion,
+but our use-newest selection method
+effectively ignores one connection or the other,
+and when one of them rekeys,
+we notice that the new SAs replace those of both old connections,
+and we then refrain from rekeying the other.
+(This duplicate detection is desirable in any event, for robustness,
+to ensure that the system converges on a reasonable state eventually
+after it is perturbed by difficulties or bugs.)
+.P
+When connections are not permanent, the situation is less happy.
+One particular situation in which we see problems is when a number of
+"Road Warrior" hosts occasionally call in to a central server.
+The server is normally configured not to initiate such connections,
+since it does not know when the Road Warrior is available (or what IP
+address it is using).
+Unfortunately, if the server crashes and reboots,
+any Road Warriors then connected have a problem:
+they don't know that the server has crashed,
+so they can't renegotiate,
+and the server has forgotten both the connections and
+their (transient) IP addresses,
+so it cannot renegotiate.
+.P
+We believe that the simplest answer to this problem is what John Denker
+has dubbed "address inertia":
+the server makes a best-effort attempt to remember (in nonvolatile storage)
+which connections were active and what the far-end addresses were
+(and what the successful proposal's parameters were),
+so that it can attempt renegotiation on reboot.
+We have not implemented this yet, but intend to;
+Denker has implemented it himself,
+although in a somewhat messy way,
+and reports excellent results.
+.H
+5.4. Network Partitions
+.P
+A network partition, making the two ends unable to reach each other,
+has many of the same characteristics as having the other end crash... until
+the network reconnects.
+It is desirable that recovery from this be automatic.
+.P
+If the network reconnects before any rekeying attempts
+or other IKE activities occurred,
+recovery is fully transparent,
+because the IKEs have no idea that there was any problem.
+(Complaints such as ICMP Host Unreachable messages are unauthenticated
+and hence cannot be given much weight.)
+This fits the general mold of TCP/IP:
+if nobody wanted to send any traffic, a network outage doesn't matter.
+.P
+If IKE activity did occur,
+the IKE implementation will discover that the other end doesn't seem
+to be responding.
+The preferred response to this depends on the nature of the connection.
+If it was intended to be ephemeral (e.g. opportunistic encryption [OE]),
+closing it down after a few retries is reasonable.
+If the other end is expected to sometimes drop the connection without
+warning, it may not be desirable to retry at all.
+(We support both these forms of configurability,
+and indeed we also have a configuration option to suppress
+rekeying entirely on one end.)
+.P
+If the connection was intended to be permanent, however,
+then persistent attempts to re-establish it are appropriate.
+Some degree of backoff is appropriate here,
+so that retries get less frequent as the outage gets prolonged.
+Backoff should be limited,
+so that re-established connectivity is not followed by a long delay
+before a retry.
+Finally, after many retries (say 24 hours' worth),
+it may be preferable to just declare the connection down and rely
+on manual intervention to re-establish it,
+should this be desirable.
+We do not yet fully support all this.
+.H
+5.5. Unknown SAs
+.P
+A more complete solution to crashes
+would be for an IPsec host to note the arrival
+of ESP packets on an unknown IPsec SA,
+and report it somehow to the other host, which can then decide to renegotiate.
+This arguably might be preferable in any case\(emif
+the non-rebooted host has no traffic to send,
+it does not care whether the connection is intact\(embut
+delays and packet loss will be reduced
+if the connection is renegotiated BEFORE there is traffic for it.
+So unknown-SA detection is best reserved as a fallback method,
+with address inertia used to deal with most such cases.
+.P
+A difficulty with unknown-SA detection is,
+just HOW should the other host be notified?
+IKE provides no good way to do the notification:
+Notification payloads (e.g., Initial-Contact) are unauthenticated
+unless they are sent under protection of an ISAKMP SA.
+A "Security Failures - Bad SPI" ICMP message [SECFAIL]
+is an interesting alternative,
+but has the disadvantage of likewise being unauthenticated.
+It's fundamentally unlikely that there is a simple solution to this,
+given that almost any way of arranging or checking authentication for such a
+notification is costly.
+.P
+We think the best answer to this is a two-step approach.
+An unauthenticated Initial-Contact or
+Security Failures - Bad SPI cannot be taken as a reliable
+report of a problem,
+but can be taken as a hint that a problem MIGHT exist.
+Then there needs to be some reliable way of checking such hints,
+subject to rate limiting since the checks are likely to be costly
+(and checking the same connection repeatedly at short intervals is unlikely
+to be worthwhile anyway).
+So the rebooted host sends the notification,
+and the non-rebooted host\(emwhich still thinks it has a connection\(emchecks
+whether the connection still works,
+and renegotiates if not.
+.P
+Also, if an IPsec host which believes it has a connection to another host
+sees an unsuccessful attempt by that host to negotiate a new one,
+that is also a hint of possible problems,
+justifying a check and possible renegotiation.
+("Unsuccessful" here means a negotiation failure due to lack of a
+satisfactory proposal.
+A failure due to authentication failure
+suggests a denial-of-service attack by a third party,
+rather than a genuine problem on the legitimate other end.)
+As noted in section 4.2,
+it is possible for negotiations to succeed or fail based on which
+end initiates them, and some robustness against that is desirable.
+.P
+We have not yet decided what form the notification should take.
+IKE Initial-Contact is an obvious possibility,
+but has some disadvantages.
+It does not specify which connection has had difficulties.
+Also, the specification [IKE section 4.6.3.3]
+refers to "remote system" and "sending system"
+without clearly specifying just what "system" means;
+in the case of a multi-homed host using multiple forms of identification,
+the question is not trivial.
+Initial-Contact does have the fairly-decisive advantage
+that it is likely to convey the right general
+meaning even to an implementation which does not do things
+exactly the way ours does.
+.P
+A more fundamental difficulty is what form the reliable check takes.
+What is wanted is an "IKE ping",
+verifying that the ISAKMP SA is still intact
+(it being unlikely that IPsec SAs have been lost while the ISAKMP SA has not).
+The lack of such a facility is a serious failing of IKE.
+An acknowledged Notification of some sort would be ideal,
+but there is none at present.
+Some existing implementations are known
+to use the private Notification values 30000 as ping
+and 30002 as ping reply,
+and that seems the most attractive choice at present.
+If it is not recognized, there will probably be no reply,
+and the result will be an unnecessary renegotiation,
+so this needs strict rate limiting.
+(Also, when a new connection is set up,
+it's probably worth determining by experiment whether the other end
+supports IKE ping, and remembering that.)
+.P
+While we think this facility is desirable,
+and is about the best that can be done with the poor tools available,
+we have not gotten very far in implementation and cannot comment
+intelligently about how well it works or interoperates.
+.H
+6. Misc. IKE Issues
+.H
+6.1. Groups 1 and 5
+.P
+We have dropped support for the first Oakley Group (group 1),
+despite it being officially mandatory,
+on the grounds that it is
+grossly too weak to provide enough randomness for 3DES.
+There have been some interoperability problems,
+mostly quite minor:
+ALMOST everyone supports group 2 as well,
+although sometimes it has to be explicitly configured.
+.P
+We also support the quasi-standard group 5 [GROUPS].
+This has not been seriously exercised yet,
+because historically
+we offered group 2 first and almost everyone accepted it.
+We have recently changed to offering group 5 first,
+and no difficulties have been reported.
+.H
+6.2. To PFS Or Not To PFS
+.P
+A persistent small interoperability problem is that
+the presence or absence of PFS (for keys [IKE, section 5.5])
+is neither negotiated nor announced.
+We have it enabled by default,
+and successful interoperation often requires having
+the other end turn it on in their implementation,
+or having the FreeS/WAN end disable it.
+Almost everyone supports it, but it's usually not the default,
+and interoperability is often impossible unless the two ends
+somehow reach prior agreement on it.
+.P
+We do not explicitly support the other flavor of PFS,
+for identities [IKE, section 8],
+and this has caused no interoperability problems.
+.H
+6.3. Debugging Tools, Lack Thereof
+.P
+We find IKE lacking in basic debugging tools.
+Section 5.4, above,
+notes that an IKE ping would be useful for connectivity verification.
+It would also be extremely helpful for determining that UDP/500
+packets get back and forth successfully between the two ends,
+which is often an important first step in debugging.
+.P
+It's also quite common to have IKE negotiate a connection successfully,
+but to have some firewall along the way blocking ESP.
+Users find this mysterious and difficult to diagnose.
+We have no immediate suggestions on what could be done about it.
+.H
+6.4. Terminology, Vagueness Thereof
+.P
+The terminology of IPsec needs work.
+We feel that both the specifications and user-oriented
+documentation would be greatly clarified by concise, intelligible names for
+certain concepts.
+.P
+We semi-consistently use "group" for the set of IPsec SAs which are
+established in one direction
+by a single Quick Mode negotiation and are used together
+to process a packet (e.g., an ESP SA plus an AH SA),
+"connection" for the logical packet path provided
+by a succession of pairs of groups
+(each rekeying providing a new pair, one group in each direction),
+and "keying channel" for the corresponding supervisory path provided
+by a sequence of ISAKMP SAs.
+.P
+We think it's a botch that "PFS" is used to refer to two very different things,
+but we have no specific new terms to suggest, since we only implement
+one kind of PFS and thus can just ignore the other.
+.H
+6.5. A Question of Identity
+.P
+One specification problem deserves note:
+exactly when can an existing phase 1 negotiation
+be re-used for a new phase 2 negotiation,
+as IKE [IKE, section 4] specifies?
+Presumably,
+when it connects the same two "parties"... but exactly what is a "party"?
+.P
+As noted in section 5.4,
+in cases involving multi-homing and multiple identities,
+it's not clear exactly what criteria are used for deciding
+whether the intended far end for a new negotiation is the same one
+as for a previous negotiation.
+Is it by Identification Payload?
+By IP address?
+Or what?
+.P
+We currently use a somewhat-vague notion of "identity",
+basically what gets sent in Identification Payloads,
+for this, and this seems to be successful,
+but we think this needs better specification.
+.H
+6.6. Opportunistic Encryption
+.P
+Further IKE challenges appear in the context of Opportunistic Encryption
+[OE],
+but operational experience with it is too limited as yet for us
+to comment usefully right now.
+.H
+6.7. Authentication and RSA Keys
+.P
+We provide two IKE authentication methods:
+shared secrets ("pre-shared keys")
+and RSA digital signatures.
+(A user-provided add-on package generalizes the latter to limited
+support for certificates;
+we have not worked extensively with it ourselves yet and cannot comment
+on it yet.)
+.P
+Shared secrets, despite their administrative difficulties,
+see considerable use,
+and are also the method of last resort for interoperability problems.
+.P
+For digital signatures,
+we have taken the somewhat unorthodox approach of using "bare" RSA public keys,
+either supplied in configuration files or fetched from DNS,
+rather than getting involved in the complexity of certificates.
+We encode our RSA public keys using the DNS KEY encoding [DNSRSA]
+(aka "RFC 2537", although that RFC is now outdated),
+which has given us no difficulties and which we highly recommend.
+We have seen two difficulties in connection with RSA keys, however.
+.P
+First,
+while a number of IPsec implementations are able to take "bare" RSA public keys,
+each one seems to have its own idea of what format should be used
+for transporting them.
+We've had little success with interoperability here,
+mostly because of key-format issues;
+the implementations generally WILL interoperate successfully if you can
+somehow get an RSA key into them at all, but that's hard.
+X.509 certificates seem to be the lowest (!)
+common denominator for key transfer.
+.P
+Second,
+although the content of RSA public keys has been stable,
+there has been a small but subtle change over time in the content
+of RSA private keys.
+The "internal modulus",
+used to compute the private exponent "d" from the public exponent "e"
+(or vice-versa)
+was originally [RSA] [PKCS1v1] [SCHNEIER] specified to be (p-1)*(q-1),
+where p and q are the two primes.
+However, more recent definitions [PKCS1v2] call it
+"lambda(n)" and define it to be lcm(p-1,\ q-1);
+this appears to be a minor optimization.
+The result is that private keys generated with the new definition
+often fail consistency checks in implementations using the old definition.
+Fortunately, it is seldom necessary to move private keys around.
+Our software now consistently uses the new definition
+(and thus will accept keys generated with either definition),
+but our key generator also has an option to generate old-definition keys,
+for the benefit of users who upgrade their networks incrementally.
+.H
+6.8. Misc. Snags
+.P
+Nonce size is another characteristic that is neither negotiated nor announced
+but that the two ends must somehow be able to agree on.
+Our software accepts anything between 8 and 256, and defaults to 16.
+These numbers were chosen rather arbitrarily,
+but we have seen no interoperability failures here.
+.P
+Nothing in the ISAKMP [ISAKMP] or IKE [IKE] specifications says
+explicitly that a normal Message ID must be non-zero,
+but a zero Message ID in fact causes failures.
+.P
+Similarly, there is nothing in the specs which says that ISAKMP cookies
+must be non-zero, but zero cookies will in fact cause trouble.
+.H
+7. Security Considerations
+.P
+Since this document discusses aspects of building robust and
+interoperable IPsec implementations,
+security considerations permeate it.
+.H
+8. References
+.R AH
+Kent, S., and Atkinson, R.,
+"IP Authentication Header",
+RFC 2402,
+Nov 1998.
+.R CIPHERS
+Pereira, R., and Adams, R.,
+"The ESP CBC-Mode Cipher Algorithms",
+RFC 2451,
+Nov 1998.
+.R CRACK
+Electronic Frontier Foundation,
+"Cracking DES:
+Secrets of Encryption Research, Wiretap Politics and Chip Design",
+O'Reilly 1998,
+ISBN 1-56592-520-3.
+.R DES
+Madson, C., and Doraswamy, N.,
+"The ESP DES-CBC Cipher Algorithm",
+RFC 2405,
+Nov 1998.
+.R DNSRSA
+D. Eastlake 3rd,
+"RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)",
+RFC 3110,
+May 2001.
+.R ESP
+Kent, S., and Atkinson, R.,
+"IP Encapsulating Security Payload (ESP)",
+RFC 2406,
+Nov 1998.
+.R GROUPS
+Kivinen, T., and Kojo, M.,
+"More MODP Diffie-Hellman groups for IKE",
+<draft-ietf-ipsec-ike-modp-groups-04.txt>,
+13 Dec 2001 (work in progress).
+.R IKE
+Harkins, D., and Carrel, D.,
+"The Internet Key Exchange (IKE)",
+RFC 2409, Nov 1998.
+.R IPSEC
+Kent, S., and Atkinson, R.,
+"Security Architecture for the Internet Protocol",
+RFC 2401, Nov 1998.
+.R ISAKMP
+Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
+"Internet Security Association and Key Management Protocol (ISAKMP)",
+RFC 2408, Nov 1998.
+.R OE
+Richardson, M., Redelmeier, D. H., and Spencer, H.,
+"A method for doing opportunistic encryption with IKE",
+<draft-richardson-ipsec-opportunistic-06.txt>,
+21 Feb 2002 (work in progress).
+.R PKCS1v1
+Kaliski, B.,
+"PKCS #1: RSA Encryption, Version 1.5",
+RFC 2313, March 1998.
+.R PKCS1v2
+Kaliski, B., and Staddon, J.,
+"PKCS #1: RSA Cryptography Specifications, Version 2.0",
+RFC 2437, Oct 1998.
+.R PFKEY
+McDonald, D., Metz, C., and Phan, B.,
+"PF_KEY Key Management API, Version 2",
+RFC 2367, July 1998.
+.R REKEY
+Tim Jenkins, "IPsec Re-keying Issues",
+<draft-jenkins-ipsec-rekeying-06.txt>,
+2 May 2000 (draft expired, work no longer in progress).
+.R REPLAY
+Krywaniuk, A.,
+"Using Isakmp Message Ids for Replay Protection",
+<draft-krywaniuk-ipsec-antireplay-00.txt>,
+9 July 2001
+(work in progress).
+.R RSA
+Rivest, R.L., Shamir, A., and Adleman, L.,
+"A Method for Obtaining Digital Signatures and Public-Key
+Cryptosystems",
+Communications of the ACM v21n2, Feb 1978, p. 120.
+.R SCHNEIER
+Bruce Schneier, "Applied Cryptography", 2nd ed.,
+Wiley 1996, ISBN 0-471-11709-9.
+.R SECFAIL
+Karn, P., and Simpson, W.,
+"ICMP Security Failures Messages",
+RFC 2521,
+March 1999.
+.H
+Authors' Addresses
+.P
+.nf
+.ne 8
+Henry Spencer
+SP Systems
+Box 280 Stn. A
+Toronto, Ont. M5W1B2
+Canada
+
+henry@spsystems.net
+416-690-6561
+.ne 8
+.sp 2
+D. Hugh Redelmeier
+Mimosa Systems Inc.
+29 Donino Ave.
+Toronto, Ont. M4N2W6
+Canada
+
+hugh@mimosa.com
+416-482-8253
+.bp
+.H
+Full Copyright Statement
+.P
+Copyright (C) The Internet Society \*c. All Rights
+Reserved.
+
+This document and translations of it may be copied and
+furnished to others, and derivative works that comment on or
+otherwise explain it or assist in its implmentation may be
+prepared, copied, published and distributed, in whole or in
+part, without restriction of any kind, provided that the above
+copyright notice and this paragraph are included on all such
+copies and derivative works.  However, this document itself may
+not be modified in any way, such as by removing the copyright
+notice or references to the Internet Society or other Internet
+organizations, except as needed for the  purpose of developing
+Internet standards in which case the procedures for copyrights
+defined in the Internet Standards process must be followed, or
+as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will
+not be revoked by the Internet Society or its successors or
+assigns.
+
+This document and the information contained herein is provided
+on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
+ENGINEERING TASK FORCE DISCLAIMS 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.
diff --git a/doc/draft-spencer-ipsec-ike-implementation.txt b/doc/draft-spencer-ipsec-ike-implementation.txt
new file mode 100644
index 000000000..145c00ba8
--- /dev/null
+++ b/doc/draft-spencer-ipsec-ike-implementation.txt
@@ -0,0 +1,1232 @@
+
+
+
+Network Working Group                                      Henry Spencer
+Internet Draft                                                SP Systems
+Expires: 26 Aug 2002                                  D. Hugh Redelmeier
+                                                          Mimosa Systems
+                                                             26 Feb 2002
+
+                       IKE Implementation Issues
+            <draft-spencer-ipsec-ike-implementation-02.txt>
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   (If approved as an Informational RFC...)  This memo provides
+   information for the Internet community.  This memo does not specify
+   an Internet standard of any kind.
+
+   Distribution of this memo is unlimited.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on 26 Aug 2002.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2002.  All Rights Reserved.
+
+
+
+
+
+
+
+
+
+
+Spencer & Redelmeier                                            [Page 1]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+Table of Contents
+
+   1. Introduction ................................................... 3
+   2. Lower-level Background and Notes ............................... 4
+   2.1. Packet Handling .............................................. 4
+   2.2. Ciphers ...................................................... 5
+   2.3. Interfaces ................................................... 5
+   3. IKE Infrastructural Issues ..................................... 5
+   3.1. Continuous Channel ........................................... 5
+   3.2. Retransmission ............................................... 5
+   3.3. Replay Prevention ............................................ 6
+   4. Basic Keying and Rekeying ...................................... 7
+   4.1. When to Create SAs ........................................... 7
+   4.2. When to Rekey ................................................ 8
+   4.3. Choosing an SA ............................................... 9
+   4.4. Why to Rekey ................................................. 9
+   4.5. Rekeying ISAKMP SAs ......................................... 10
+   4.6. Bulk Negotiation ............................................ 10
+   5. Deletions, Teardowns, Crashes ................................. 11
+   5.1. Deletions ................................................... 11
+   5.2. Teardowns and Shutdowns ..................................... 12
+   5.3. Crashes ..................................................... 13
+   5.4. Network Partitions .......................................... 13
+   5.5. Unknown SAs ................................................. 14
+   6. Misc. IKE Issues .............................................. 16
+   6.1. Groups 1 and 5 .............................................. 16
+   6.2. To PFS Or Not To PFS ........................................ 16
+   6.3. Debugging Tools, Lack Thereof ............................... 16
+   6.4. Terminology, Vagueness Thereof .............................. 17
+   6.5. A Question of Identity ...................................... 17
+   6.6. Opportunistic Encryption .................................... 17
+   6.7. Authentication and RSA Keys ................................. 17
+   6.8. Misc. Snags ................................................. 18
+   7. Security Considerations ....................................... 19
+   8. References .................................................... 19
+   Authors' Addresses ............................................... 20
+   Full Copyright Statement ......................................... 21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Spencer & Redelmeier                                            [Page 2]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+Abstract
+
+   The current IPsec specifications for key exchange and connection
+   management, RFCs 2408 [ISAKMP] and 2409 [IKE], leave many aspects of
+   connection management unspecified, most prominently rekeying
+   practices.  Pending clarifications in future revisions of the
+   specifications, this document sets down some successful experiences,
+   to minimize the extent to which new implementors have to rely on
+   unwritten folklore.
+
+   The Linux FreeS/WAN implementation of IPsec interoperates with almost
+   every other IPsec implementation.  This document describes how the
+   FreeS/WAN project has resolved some of the gaps in the IPsec
+   specifications (and plans to resolve some others), and what
+   difficulties have been encountered, in hopes that this generally-
+   successful experience might be informative to new implementors.
+
+   This is offered as an Informational RFC.
+
+   This -02 revision mainly: discusses ISAKMP SA expiry during IPsec-SA
+   rekeying (4.5), revises the discussion of bidirectional Deletes
+   (5.1), suggests remembering the parameters of successful negotiations
+   for later use (4.2, 5.3), notes an unsuccessful negotiation from the
+   other end as a hint of a possibly broken connection (5.5), and adds
+   sections on network partitions (5.4), authentication methods and the
+   subtleties of RSA public keys (6.7), and miscellaneous
+   interoperability concerns (6.8).
+
+1. Introduction
+
+   The current IPsec specifications for key exchange and connection
+   management, RFCs 2408 [ISAKMP] and 2409 [IKE], leave many aspects of
+   connection management unspecified, most prominently rekeying
+   practices.  This is a cryptic puzzle which each group of implementors
+   has to struggle with, and differences in how the ambiguities and gaps
+   are resolved are potentially a fruitful source of interoperability
+   problems.  We can hope that future revisions of the specifications
+   will clear this up.  Meanwhile, it seems useful to set down some
+   successful experiences, to minimize the extent to which new
+   implementors have to rely on unwritten folklore.
+
+   The Linux FreeS/WAN implementation of IPsec interoperates with almost
+   every other IPsec implementation, and because of its free nature, it
+   also sees some use as a reference implementation by other
+   implementors.  The high degree of interoperability is noteworthy
+   given its organizers' strong minimalist bias, which has caused them
+   to implement only a small subset of the full glory of IPsec.  This
+   document describes how the FreeS/WAN project has resolved some of the
+
+
+
+Spencer & Redelmeier                                            [Page 3]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   gaps in the IPsec specifications (and plans to resolve some others),
+   and what difficulties have been encountered, in hopes that this
+   generally-successful experience might be informative to new
+   implementors.
+
+   One small caution about applicability: this experience may not be
+   relevant to severely resource-constrained implementations.
+   FreeS/WAN's target environment is previous-generation PCs, now
+   available at trivial cost (often, within an organization, at no
+   cost), which have quite impressive CPU power and memory by the
+   standards of only a few years ago.  Some of the approaches discussed
+   here may be inapplicable to implementations with severe external
+   constraints which prevent them from taking advantage of modern
+   hardware technology.
+
+2. Lower-level Background and Notes
+
+2.1. Packet Handling
+
+   FreeS/WAN implements ESP [ESP] and AH [AH] straightforwardly,
+   although AH sees little use among our users.  Our ESP/AH
+   implementation cannot currently handle packets with IP options;
+   somewhat surprisingly, this has caused little difficulty.  We insist
+   on encryption and do not support authentication-only connections, and
+   this has not caused significant difficulty either.
+
+   MTU and fragmentation issues, by contrast, have been a constant
+   headache.  We will not describe the details of our current approach
+   to them, because it still needs work.  One difficulty we have
+   encountered is that many combinations of packet source and packet
+   destination apparently cannot cope with an "interior minimum" in the
+   path MTU, e.g. where an IPsec tunnel intervenes and its headers
+   reduce the MTU for an intermediate link.  This is particularly
+   prevalent when using common PC software to connect to large well-
+   known web sites; we think it is largely due to misconfigured
+   firewalls which do not pass ICMP Fragmentation Required messages.
+   The only solution we have yet found is to lie about the MTU of the
+   tunnel, accepting the (undesirable) fragmentation of the ESP packets
+   for the sake of preserving connectivity.
+
+   We currently zero out the TOS field of ESP packets, rather than
+   copying it from the inner header, on the grounds that it lends itself
+   too well to traffic analysis and covert channels.  We provide an
+   option to restore RFC 2401 [IPSEC] copying behavior, but this appears
+   to see little use.
+
+
+
+
+
+
+Spencer & Redelmeier                                            [Page 4]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+2.2. Ciphers
+
+   We initially implemented both DES [DES] and 3DES [CIPHERS] for both
+   IKE and ESP, but after the Deep Crack effort [CRACK] demonstrated its
+   inherent insecurity, we dropped support for DES.  Somewhat
+   surprisingly, our insistence on 3DES has caused almost no
+   interoperability problems, despite DES being officially mandatory.  A
+   very few other systems either do not support 3DES or support it only
+   as an optional upgrade, which inconveniences a few would-be users.
+   There have also been one or two cases of systems which don't quite
+   seem to know the difference!
+
+   See also section 6.1 for a consequence of our insistence on 3DES.
+
+2.3. Interfaces
+
+   We currently employ PF_KEY version 2 [PFKEY], plus various non-
+   standard extensions, as our interface between keying and ESP.  This
+   has not proven entirely satisfactory.  Our feeling now is that keying
+   issues and policy issues do not really lend themselves to the clean
+   separation that PF_KEY envisions.
+
+3. IKE Infrastructural Issues
+
+   A number of problems in IPsec connection management become easier if
+   some attention is first paid to providing an infrastructure to
+   support solving them.
+
+3.1. Continuous Channel
+
+   FreeS/WAN uses an approximation to the "continuous channel" model, in
+   which ISAKMP SAs are maintained between IKEs so long as any IPsec SAs
+   are open between the two systems.  The resource consumption of this
+   is minor: the only substantial overhead is occasional rekeying.
+   IPsec SA management becomes significantly simpler if there is always
+   a channel for transmission of control messages.  We suggest (although
+   we do not yet fully implement this) that inability to maintain (e.g.,
+   to rekey) this control path should be grounds for tearing down the
+   IPsec SAs as well.
+
+   As a corollary of this, there is one and only one ISAKMP SA
+   maintained between a pair of IKEs (although see sections 5.3 and 6.5
+   for minor complications).
+
+3.2. Retransmission
+
+   The unreliable nature of UDP transmission is a nuisance.  IKE
+   implementations should always be prepared to retransmit the most
+
+
+
+Spencer & Redelmeier                                            [Page 5]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   recent message they sent on an ISAKMP SA, since there is some
+   possibility that the other end did not get it.  This means, in
+   particular, that the system sending the supposedly-last message of an
+   exchange cannot relax and assume that the exchange is complete, at
+   least not until a significant timeout has elapsed.
+
+   Systems must also retain information about the message most recently
+   received in an exchange, so that a duplicate of it can be detected
+   (and possibly interpreted as a NACK for the response).
+
+   The retransmission rules FreeS/WAN follows are: (1) if a reply is
+   expected, retransmit only if it does not appear before a timeout; and
+   (2) if a reply is not expected (last message of the exchange),
+   retransmit only on receiving a retransmission of the previous
+   message.  Notably, in case (1) we do NOT retransmit on receiving a
+   retransmission, which avoids possible congestion problems arising
+   from packet duplication, at the price of slowing response to packet
+   loss.  The timeout for case (1) is 10 seconds for the first retry, 20
+   seconds for the second, and 40 seconds for all subsequent retries
+   (normally only one, except when configuration settings call for
+   persistence and the message is the first message of Main Mode with a
+   new peer).  These retransmission rules have been entirely successful.
+
+   (Michael Thomas of Cisco has pointed out that the retry timeouts
+   should include some random jitter, to de-synchronize hosts which are
+   initially synchronized by, e.g., a power outage.  We already jitter
+   our rekeying times, as noted in section 4.2, but that does not help
+   with initial startup.  We're implementing jittered retries, but
+   cannot yet report on experience with this.)
+
+   There is a deeper problem, of course, when an entire "exchange"
+   consists of a single message, e.g. the ISAKMP Informational Exchange.
+   Then there is no way to decide whether or when a retransmission is
+   warranted at all.  This seems like poor design, to put it mildly (and
+   there is now talk of fixing it).  We have no experience in dealing
+   with this problem at this time, although it is part of the reason why
+   we have delayed implementing Notification messages.
+
+3.3. Replay Prevention
+
+   The unsequenced nature of UDP transmission is also troublesome,
+   because it means that higher levels must consider the possibility of
+   replay attacks.  FreeS/WAN takes the position that systematically
+   eliminating this possibility at a low level is strongly preferable to
+   forcing careful consideration of possible impacts at every step of an
+   exchange.  RFC 2408 [ISAKMP] section 3.1 states that the Message ID
+   of an ISAKMP message must be "unique".  FreeS/WAN interprets this
+   literally, as forbidding duplication of Message IDs within the set of
+
+
+
+Spencer & Redelmeier                                            [Page 6]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   all messages sent via a single ISAKMP SA.
+
+   This requires remembering all Message IDs until the ISAKMP SA is
+   superseded by rekeying, but that is not costly (four bytes per sent
+   or received message), and it ELIMINATES replay attacks from
+   consideration; we believe this investment of resources is well
+   worthwhile.  If the resource consumption becomes excessive--in our
+   experience it has not--the ISAKMP SA can be rekeyed early to collect
+   the garbage.
+
+   There is theoretically an interoperability problem when talking to
+   implementations which interpret "unique" more loosely and may re-use
+   Message IDs, but it has not been encountered in practice.  This
+   approach appears to be completely interoperable.
+
+   The proposal by Andrew Krywaniuk [REPLAY], which advocates turning
+   the Message ID into an anti-replay counter, would achieve the same
+   goal without the minor per-message memory overhead.  This may be
+   preferable, although it means an actual protocol change and more
+   study is needed.
+
+4. Basic Keying and Rekeying
+
+4.1. When to Create SAs
+
+   As Tim Jenkins [REKEY] pointed out, there is a potential race
+   condition in Quick Mode: a fast lightly-loaded Initiator might start
+   using IPsec SAs very shortly after sending QM3 (the third and last
+   message of Quick Mode), while a slow heavily-loaded Responder might
+   not be ready to receive them until after spending a significant
+   amount of time creating its inbound SAs.  The problem is even worse
+   if QM3 gets delayed or lost.
+
+   FreeS/WAN's approach to this is what Jenkins called "Responder Pre-
+   Setup": the Responder creates its inbound IPsec SAs before it sends
+   QM2, so they are always ready and waiting when the Initiator sends
+   QM3 and begins sending traffic.  This approach is simple and
+   reliable, and in our experience it interoperates with everybody.
+   (There is potentially still a problem if FreeS/WAN is the Initiator
+   and the Responder does not use Responder Pre-Setup, but no such
+   problems have been seen.)  The only real weakness of Responder Pre-
+   Setup is the possibility of replay attacks, which we have eliminated
+   by other means (see section 3.3).
+
+   With this approach, the Commit Bit is useless, and we ignore it.  In
+   fact, until quite recently we discarded any IKE message containing
+   it, and this caused surprisingly few interoperability problems;
+   apparently it is not widely used.  We have recently been persuaded
+
+
+
+Spencer & Redelmeier                                            [Page 7]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   that simply ignoring it is preferable; preliminary experience with
+   this indicates that the result is successful interoperation with
+   implementations which set it.
+
+4.2. When to Rekey
+
+   To preserve connectivity for user traffic, rekeying of a connection
+   (that is, creation of new IPsec SAs to supersede the current ones)
+   must begin before its current IPsec SAs expire.  Preferably one end
+   should predictably start rekeying negotiations first, to avoid the
+   extra overhead of two simultaneous negotiations, although either end
+   should be prepared to rekey if the other does not.  There is also a
+   problem with "convoys" of keying negotiations: for example, a "hub"
+   gateway with many IPsec connections can be inundated with rekeying
+   negotiations exactly one connection-expiry time after it reboots, and
+   the massive overload this induces tends to make this situation self-
+   perpetuating, so it recurs regularly.  (Convoys can also evolve
+   gradually from initially-unsynchronized negotiations.)
+
+   FreeS/WAN has the concept of a "rekeying margin", measured in
+   seconds.  If FreeS/WAN was the Initiator for the previous rekeying
+   (or the startup, if none) of the connection, it nominally starts
+   rekeying negotiations at expiry time minus one rekeying margin.  Some
+   random jitter is added to break up convoys: rather than starting
+   rekeying exactly at minus one margin, it starts at a random time
+   between minus one margin and minus two margins.  (The randomness here
+   need not be cryptographic in quality, so long as it varies over time
+   and between hosts.  We use an ordinary PRNG seeded with a few bytes
+   from a cryptographic randomness source.  The seeding mostly just
+   ensures that the PRNG sequence is different for different hosts, even
+   if they start up simultaneously.)
+
+   If FreeS/WAN was the Responder for the previous rekeying/startup, and
+   nothing has been heard from the previous Initiator at expiry time
+   minus one-half the rekeying margin, FreeS/WAN will initiate rekeying
+   negotiations.  No jitter is applied; we now believe that it should be
+   jittered, say between minus one-half margin and minus one-quarter
+   margin.
+
+   Having the Initiator lead the way is an obvious way of deciding who
+   should speak first, since there is already an Initiator/Responder
+   asymmetry in the connection.  Moreover, our experience has been that
+   Initiator lead gives a significantly higher probability of successful
+   negotiation!  The negotiation process itself is asymmetric, because
+   the Initiator must make a few specific proposals which the Responder
+   can only accept or reject, so the Initiator must try to guess where
+   its "acceptable" region (in parameter space) might overlap with the
+   Responder's.  We have seen situations where negotiations would
+
+
+
+Spencer & Redelmeier                                            [Page 8]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   succeed or fail depending on which end initiated them, because one
+   end was making better guesses.  Given an existing connection, we KNOW
+   that the previous Initiator WAS able to initiate a successful
+   negotiation, so it should (if at all possible) take the lead again.
+   Also, the Responder should remember the Initiator's successful
+   proposal, and start from that rather than from his own default
+   proposals if he must take the lead; we don't currently implement this
+   completely but plan to.
+
+   FreeS/WAN defaults the rekeying margin to 9 minutes, although this
+   can be changed by configuration.  There is also a configuration
+   option to alter the permissible range of jitter.  The defaults were
+   chosen somewhat arbitrarily, but they work extremely well and the
+   configuration options are rarely used.
+
+4.3. Choosing an SA
+
+   Once rekeying has occurred, both old and new IPsec SAs for the
+   connection exist, at least momentarily.  FreeS/WAN accepts incoming
+   traffic on either old or new inbound SAs, but sends outgoing traffic
+   only on the new outbound ones.  This approach appears to be
+   significantly more robust than using the old ones until they expire,
+   notably in cases where renegotiation has occurred because something
+   has gone wrong on the other end.  It avoids having to pay meticulous
+   attention to the state of the other end, state which is difficult to
+   learn reliably given the limitations of IKE.
+
+   This approach has interoperated successfully with ALMOST all other
+   implementations.  The only (well-characterized) problem cases have
+   been implementations which rely on receiving a Delete message for the
+   old SAs to tell them to switch over to the new ones.  Since delivery
+   of Delete is unreliable, and support for Delete is optional, this
+   reliance seems like a serious mistake.  This is all the more true
+   because Delete announces that the deletion has already occurred
+   [ISAKMP, section 3.15], not that it is about to occur, so packets
+   already in transit in the other direction could be lost.  Delete
+   should be used for resource cleanup, not for switchover control.
+   (These matters are discussed further in section 5.)
+
+4.4. Why to Rekey
+
+   FreeS/WAN currently implements only time-based expiry (life in
+   seconds), although we are working toward supporting volume-based
+   expiry (life in kilobytes) as well.  The lack of volume-based expiry
+   has not been an interoperability problem so far.
+
+   Volume-based expiry does add some minor complications.  In
+   particular, it makes explicit Delete of now-disused SAs more
+
+
+
+Spencer & Redelmeier                                            [Page 9]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   important, because once an SA stops being used, it might not expire
+   on its own.  We believe this lacks robustness and is generally
+   unwise, especially given the lack of a reliable Delete, and expect to
+   use volume-based expiry only as a supplement to time-based expiry.
+   However, Delete support (see section 5) does seem advisable for use
+   with volume-based expiry.
+
+   We do not believe that volume-based expiry alters the desirability of
+   switching immediately to the new SAs after rekeying.  Rekeying
+   margins are normally a small fraction of the total life of an SA, so
+   we feel there is no great need to "use it all up".
+
+4.5. Rekeying ISAKMP SAs
+
+   The above discussion has focused on rekeying for IPsec SAs, but
+   FreeS/WAN applies the same approaches to rekeying for ISAKMP SAs,
+   with similar success.
+
+   One issue which we have noticed, but not explicitly dealt with, is
+   that difficulties may ensue if an IPsec-SA rekeying negotiation is in
+   progress at the time when the relevant ISAKMP SA gets rekeyed.  The
+   IKE specification [IKE] hints, but does not actually say, that a
+   Quick Mode negotiation should remain on a single ISAKMP SA
+   throughout.
+
+   A reasonable rekeying margin will generally prevent the old ISAKMP SA
+   from actually expiring during a negotiation.  Some attention may be
+   needed to prevent in-progress negotiations from being switched to the
+   new ISAKMP SA.  Any attempt at pre-expiry deletion of the ISAKMP SA
+   must be postponed until after such dangling negotiations are
+   completed, and there should be enough delay between ISAKMP-SA
+   rekeying and a deletion attempt to (more or less) ensure that there
+   are no negotiation-starting packets still in transit from before the
+   rekeying.
+
+   At present, FreeS/WAN does none of this, and we don't KNOW of any
+   resulting trouble.  With normal lifetimes, the problem should be
+   uncommon, and we speculate that an occasional disrupted negotiation
+   simply gets retried.
+
+4.6. Bulk Negotiation
+
+   Quick Mode nominally provides for negotiating possibly-large numbers
+   of similar but unrelated IPsec SAs simultaneously [IKE, section 9].
+   Nobody appears to do this.  FreeS/WAN does not support it, and its
+   absence has caused no problems.
+
+
+
+
+
+Spencer & Redelmeier                                           [Page 10]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+5. Deletions, Teardowns, Crashes
+
+   FreeS/WAN currently ignores all Notifications and Deletes, and never
+   generates them.  This has caused little difficulty in
+   interoperability, which shouldn't be surprising (since Notification
+   and Delete support is officially entirely optional) but does seem to
+   surprise some people.  Nevertheless, we do plan some changes to this
+   approach based on past experience.
+
+5.1. Deletions
+
+   As hinted at above, we plan to implement Delete support, done as
+   follows.  Shortly after rekeying of IPsec SAs, the Responder issues a
+   Delete for its old inbound SAs (but does not actually delete them
+   yet).  The Responder initiates this because the Initiator started
+   using the new SAs on sending QM3, while the Responder started using
+   them only on (or somewhat after) receiving QM3, so there is less
+   chance of old-SA packets still being in transit from the Initiator.
+   The Initiator issues an unsolicited Delete only if it does not hear
+   one from the Responder after a longer delay.
+
+   Either party, on receiving a Delete for one or more of the old
+   outbound SAs of a connection, deletes ALL the connection's SAs, and
+   acknowledges with a Delete for the old inbound SAs.  A Delete for
+   nonexistent SAs (e.g., SAs which have already been expired or
+   deleted) is ignored.  There is no retransmission of unacknowledged
+   Deletes.
+
+   In the normal case, with prompt reliable transmission (except
+   possibly for loss of the Responder's initial Delete) and conforming
+   implementations on both ends, this results in three Deletes being
+   transmitted, resembling the classic three-way handshake.  Loss of a
+   Delete after the first, or multiple losses, will cause the SAs not to
+   be deleted on at least one end.  It appears difficult to do much
+   better without at least a distinction between request and
+   acknowledgement.
+
+   RFC 2409 section 9 "strongly suggests" that there be no response to
+   informational messages such as Deletes, but the only rationale
+   offered is prevention of infinite loops endlessly exchanging "I don't
+   understand you" informationals.  Since Deletes cannot lead to such a
+   loop (and in any case, the nonexistent-SA rule prevents more than one
+   acknowledgement for the same connection), we believe this
+   recommendation is inapplicable here.
+
+   As noted in section 4.3, these Deletes are intended for resource
+   cleanup, not to control switching between SAs.  But we expect that
+   they will improve interoperability with some broken implementations.
+
+
+
+Spencer & Redelmeier                                           [Page 11]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   We believe strongly that connections need to be considered as a
+   whole, rather than treating each SA as an independent entity.  We
+   will issue Deletes only for the full set of inbound SAs of a
+   connection, and will treat a Delete for any outbound SA as equivalent
+   to deletion of all the outbound SAs for the associated connection.
+
+   The above is phrased in terms of IPsec SAs, but essentially the same
+   approach can be applied to ISAKMP SAs (the Deletes for the old ISAKMP
+   SA should be sent via the new one).
+
+5.2. Teardowns and Shutdowns
+
+   When a connection is not intended to be up permanently, there is a
+   need to coordinate teardown, so that both ends are aware that the
+   connection is down.  This is both for recovery of resources, and to
+   avoid routing packets through dangling SAs which can no longer
+   deliver them.
+
+   Connection teardown will use the same bidirectional exchange of
+   Deletes as discussed in section 5.1: a Delete received for current
+   IPsec SAs (not yet obsoleted by rekeying) indicates that the other
+   host wishes to tear down the associated connection.
+
+   A Delete received for a current ISAKMP SA indicates that the other
+   host wishes to tear down not only the ISAKMP SA but also all IPsec
+   SAs currently under the supervision of that ISAKMP SA.  The 5.1
+   bidirectional exchange might seem impossible in this case, since
+   reception of an ISAKMP-SA Delete indicates that the other end will
+   ignore further traffic on that ISAKMP SA.  We suggest using the same
+   tactic discussed in 5.1 for IPsec SAs: the first Delete is sent
+   without actually doing the deletion, and the response to receiving a
+   Delete is to do the deletion and reply with another Delete.  If there
+   is no response to the first Delete, retry a small number of times and
+   then give up and do the deletion; apart from being robust against
+   packet loss, this also maximizes the probability that an
+   implementation which does not do the bidirectional Delete will
+   receive at least one of the Deletes.
+
+   When a host with current connections knows that it is about to shut
+   down, it will issue Deletes for all SAs involved (both IPsec and
+   ISAKMP), advising its peers (as per the meaning of Delete [ISAKMP,
+   section 3.15]) that the SAs have become useless.  It will ignore
+   attempts at rekeying or connection startup thereafter, until it shuts
+   down.
+
+   It would be better to have a Final-Contact notification, analogous to
+   Initial-Contact but indicating that no new negotiations should be
+   attempted until further notice.  Initial-Contact actually could be
+
+
+
+Spencer & Redelmeier                                           [Page 12]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   used for shutdown notification (!), but in networks where connections
+   are intended to exist permanently, it seems likely to provoke
+   unwanted attempts to renegotiate the lost connections.
+
+5.3. Crashes
+
+   Systems sometimes crash.  Coping with the resulting loss of
+   information is easily the most difficult problem we have found in
+   implementing robust IPsec systems.
+
+   When connections are intended to be permanent, it is simple to
+   specify renegotiation on reboot.  With our approach to SA selection
+   (see section 4.3), this handles such cases robustly and well.  We do
+   have to tell users that BOTH hosts should be set this way.  In cases
+   where crashes are synchronized (e.g. by power interruptions), this
+   may result in simultaneous negotiations at reboot.  We currently
+   allow both negotiations to proceed to completion, but our use-newest
+   selection method effectively ignores one connection or the other, and
+   when one of them rekeys, we notice that the new SAs replace those of
+   both old connections, and we then refrain from rekeying the other.
+   (This duplicate detection is desirable in any event, for robustness,
+   to ensure that the system converges on a reasonable state eventually
+   after it is perturbed by difficulties or bugs.)
+
+   When connections are not permanent, the situation is less happy.  One
+   particular situation in which we see problems is when a number of
+   "Road Warrior" hosts occasionally call in to a central server.  The
+   server is normally configured not to initiate such connections, since
+   it does not know when the Road Warrior is available (or what IP
+   address it is using).  Unfortunately, if the server crashes and
+   reboots, any Road Warriors then connected have a problem: they don't
+   know that the server has crashed, so they can't renegotiate, and the
+   server has forgotten both the connections and their (transient) IP
+   addresses, so it cannot renegotiate.
+
+   We believe that the simplest answer to this problem is what John
+   Denker has dubbed "address inertia": the server makes a best-effort
+   attempt to remember (in nonvolatile storage) which connections were
+   active and what the far-end addresses were (and what the successful
+   proposal's parameters were), so that it can attempt renegotiation on
+   reboot.  We have not implemented this yet, but intend to; Denker has
+   implemented it himself, although in a somewhat messy way, and reports
+   excellent results.
+
+5.4. Network Partitions
+
+   A network partition, making the two ends unable to reach each other,
+   has many of the same characteristics as having the other end crash...
+
+
+
+Spencer & Redelmeier                                           [Page 13]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   until the network reconnects.  It is desirable that recovery from
+   this be automatic.
+
+   If the network reconnects before any rekeying attempts or other IKE
+   activities occurred, recovery is fully transparent, because the IKEs
+   have no idea that there was any problem.  (Complaints such as ICMP
+   Host Unreachable messages are unauthenticated and hence cannot be
+   given much weight.)  This fits the general mold of TCP/IP: if nobody
+   wanted to send any traffic, a network outage doesn't matter.
+
+   If IKE activity did occur, the IKE implementation will discover that
+   the other end doesn't seem to be responding.  The preferred response
+   to this depends on the nature of the connection.  If it was intended
+   to be ephemeral (e.g. opportunistic encryption [OE]), closing it down
+   after a few retries is reasonable.  If the other end is expected to
+   sometimes drop the connection without warning, it may not be
+   desirable to retry at all.  (We support both these forms of
+   configurability, and indeed we also have a configuration option to
+   suppress rekeying entirely on one end.)
+
+   If the connection was intended to be permanent, however, then
+   persistent attempts to re-establish it are appropriate.  Some degree
+   of backoff is appropriate here, so that retries get less frequent as
+   the outage gets prolonged.  Backoff should be limited, so that re-
+   established connectivity is not followed by a long delay before a
+   retry.  Finally, after many retries (say 24 hours' worth), it may be
+   preferable to just declare the connection down and rely on manual
+   intervention to re-establish it, should this be desirable.  We do not
+   yet fully support all this.
+
+5.5. Unknown SAs
+
+   A more complete solution to crashes would be for an IPsec host to
+   note the arrival of ESP packets on an unknown IPsec SA, and report it
+   somehow to the other host, which can then decide to renegotiate.
+   This arguably might be preferable in any case--if the non-rebooted
+   host has no traffic to send, it does not care whether the connection
+   is intact--but delays and packet loss will be reduced if the
+   connection is renegotiated BEFORE there is traffic for it.  So
+   unknown-SA detection is best reserved as a fallback method, with
+   address inertia used to deal with most such cases.
+
+   A difficulty with unknown-SA detection is, just HOW should the other
+   host be notified?  IKE provides no good way to do the notification:
+   Notification payloads (e.g., Initial-Contact) are unauthenticated
+   unless they are sent under protection of an ISAKMP SA.  A "Security
+   Failures - Bad SPI" ICMP message [SECFAIL] is an interesting
+   alternative, but has the disadvantage of likewise being
+
+
+
+Spencer & Redelmeier                                           [Page 14]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   unauthenticated.  It's fundamentally unlikely that there is a simple
+   solution to this, given that almost any way of arranging or checking
+   authentication for such a notification is costly.
+
+   We think the best answer to this is a two-step approach.  An
+   unauthenticated Initial-Contact or Security Failures - Bad SPI cannot
+   be taken as a reliable report of a problem, but can be taken as a
+   hint that a problem MIGHT exist.  Then there needs to be some
+   reliable way of checking such hints, subject to rate limiting since
+   the checks are likely to be costly (and checking the same connection
+   repeatedly at short intervals is unlikely to be worthwhile anyway).
+   So the rebooted host sends the notification, and the non-rebooted
+   host--which still thinks it has a connection--checks whether the
+   connection still works, and renegotiates if not.
+
+   Also, if an IPsec host which believes it has a connection to another
+   host sees an unsuccessful attempt by that host to negotiate a new
+   one, that is also a hint of possible problems, justifying a check and
+   possible renegotiation.  ("Unsuccessful" here means a negotiation
+   failure due to lack of a satisfactory proposal.  A failure due to
+   authentication failure suggests a denial-of-service attack by a third
+   party, rather than a genuine problem on the legitimate other end.)
+   As noted in section 4.2, it is possible for negotiations to succeed
+   or fail based on which end initiates them, and some robustness
+   against that is desirable.
+
+   We have not yet decided what form the notification should take.  IKE
+   Initial-Contact is an obvious possibility, but has some
+   disadvantages.  It does not specify which connection has had
+   difficulties.  Also, the specification [IKE section 4.6.3.3] refers
+   to "remote system" and "sending system" without clearly specifying
+   just what "system" means; in the case of a multi-homed host using
+   multiple forms of identification, the question is not trivial.
+   Initial-Contact does have the fairly-decisive advantage that it is
+   likely to convey the right general meaning even to an implementation
+   which does not do things exactly the way ours does.
+
+   A more fundamental difficulty is what form the reliable check takes.
+   What is wanted is an "IKE ping", verifying that the ISAKMP SA is
+   still intact (it being unlikely that IPsec SAs have been lost while
+   the ISAKMP SA has not).  The lack of such a facility is a serious
+   failing of IKE.  An acknowledged Notification of some sort would be
+   ideal, but there is none at present.  Some existing implementations
+   are known to use the private Notification values 30000 as ping and
+   30002 as ping reply, and that seems the most attractive choice at
+   present.  If it is not recognized, there will probably be no reply,
+   and the result will be an unnecessary renegotiation, so this needs
+   strict rate limiting.  (Also, when a new connection is set up, it's
+
+
+
+Spencer & Redelmeier                                           [Page 15]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   probably worth determining by experiment whether the other end
+   supports IKE ping, and remembering that.)
+
+   While we think this facility is desirable, and is about the best that
+   can be done with the poor tools available, we have not gotten very
+   far in implementation and cannot comment intelligently about how well
+   it works or interoperates.
+
+6. Misc. IKE Issues
+
+6.1. Groups 1 and 5
+
+   We have dropped support for the first Oakley Group (group 1), despite
+   it being officially mandatory, on the grounds that it is grossly too
+   weak to provide enough randomness for 3DES.  There have been some
+   interoperability problems, mostly quite minor: ALMOST everyone
+   supports group 2 as well, although sometimes it has to be explicitly
+   configured.
+
+   We also support the quasi-standard group 5 [GROUPS].  This has not
+   been seriously exercised yet, because historically we offered group 2
+   first and almost everyone accepted it.  We have recently changed to
+   offering group 5 first, and no difficulties have been reported.
+
+6.2. To PFS Or Not To PFS
+
+   A persistent small interoperability problem is that the presence or
+   absence of PFS (for keys [IKE, section 5.5]) is neither negotiated
+   nor announced.  We have it enabled by default, and successful
+   interoperation often requires having the other end turn it on in
+   their implementation, or having the FreeS/WAN end disable it.  Almost
+   everyone supports it, but it's usually not the default, and
+   interoperability is often impossible unless the two ends somehow
+   reach prior agreement on it.
+
+   We do not explicitly support the other flavor of PFS, for identities
+   [IKE, section 8], and this has caused no interoperability problems.
+
+6.3. Debugging Tools, Lack Thereof
+
+   We find IKE lacking in basic debugging tools.  Section 5.4, above,
+   notes that an IKE ping would be useful for connectivity verification.
+   It would also be extremely helpful for determining that UDP/500
+   packets get back and forth successfully between the two ends, which
+   is often an important first step in debugging.
+
+   It's also quite common to have IKE negotiate a connection
+   successfully, but to have some firewall along the way blocking ESP.
+
+
+
+Spencer & Redelmeier                                           [Page 16]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   Users find this mysterious and difficult to diagnose.  We have no
+   immediate suggestions on what could be done about it.
+
+6.4. Terminology, Vagueness Thereof
+
+   The terminology of IPsec needs work.  We feel that both the
+   specifications and user-oriented documentation would be greatly
+   clarified by concise, intelligible names for certain concepts.
+
+   We semi-consistently use "group" for the set of IPsec SAs which are
+   established in one direction by a single Quick Mode negotiation and
+   are used together to process a packet (e.g., an ESP SA plus an AH
+   SA), "connection" for the logical packet path provided by a
+   succession of pairs of groups (each rekeying providing a new pair,
+   one group in each direction), and "keying channel" for the
+   corresponding supervisory path provided by a sequence of ISAKMP SAs.
+
+   We think it's a botch that "PFS" is used to refer to two very
+   different things, but we have no specific new terms to suggest, since
+   we only implement one kind of PFS and thus can just ignore the other.
+
+6.5. A Question of Identity
+
+   One specification problem deserves note: exactly when can an existing
+   phase 1 negotiation be re-used for a new phase 2 negotiation, as IKE
+   [IKE, section 4] specifies?  Presumably, when it connects the same
+   two "parties"... but exactly what is a "party"?
+
+   As noted in section 5.4, in cases involving multi-homing and multiple
+   identities, it's not clear exactly what criteria are used for
+   deciding whether the intended far end for a new negotiation is the
+   same one as for a previous negotiation.  Is it by Identification
+   Payload?  By IP address?  Or what?
+
+   We currently use a somewhat-vague notion of "identity", basically
+   what gets sent in Identification Payloads, for this, and this seems
+   to be successful, but we think this needs better specification.
+
+6.6. Opportunistic Encryption
+
+   Further IKE challenges appear in the context of Opportunistic
+   Encryption [OE], but operational experience with it is too limited as
+   yet for us to comment usefully right now.
+
+6.7. Authentication and RSA Keys
+
+   We provide two IKE authentication methods: shared secrets ("pre-
+   shared keys") and RSA digital signatures.  (A user-provided add-on
+
+
+
+Spencer & Redelmeier                                           [Page 17]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   package generalizes the latter to limited support for certificates;
+   we have not worked extensively with it ourselves yet and cannot
+   comment on it yet.)
+
+   Shared secrets, despite their administrative difficulties, see
+   considerable use, and are also the method of last resort for
+   interoperability problems.
+
+   For digital signatures, we have taken the somewhat unorthodox
+   approach of using "bare" RSA public keys, either supplied in
+   configuration files or fetched from DNS, rather than getting involved
+   in the complexity of certificates.  We encode our RSA public keys
+   using the DNS KEY encoding [DNSRSA] (aka "RFC 2537", although that
+   RFC is now outdated), which has given us no difficulties and which we
+   highly recommend.  We have seen two difficulties in connection with
+   RSA keys, however.
+
+   First, while a number of IPsec implementations are able to take
+   "bare" RSA public keys, each one seems to have its own idea of what
+   format should be used for transporting them.  We've had little
+   success with interoperability here, mostly because of key-format
+   issues; the implementations generally WILL interoperate successfully
+   if you can somehow get an RSA key into them at all, but that's hard.
+   X.509 certificates seem to be the lowest (!)  common denominator for
+   key transfer.
+
+   Second, although the content of RSA public keys has been stable,
+   there has been a small but subtle change over time in the content of
+   RSA private keys.  The "internal modulus", used to compute the
+   private exponent "d" from the public exponent "e" (or vice-versa) was
+   originally [RSA] [PKCS1v1] [SCHNEIER] specified to be (p-1)*(q-1),
+   where p and q are the two primes.  However, more recent definitions
+   [PKCS1v2] call it "lambda(n)" and define it to be lcm(p-1, q-1); this
+   appears to be a minor optimization.  The result is that private keys
+   generated with the new definition often fail consistency checks in
+   implementations using the old definition.  Fortunately, it is seldom
+   necessary to move private keys around.  Our software now consistently
+   uses the new definition (and thus will accept keys generated with
+   either definition), but our key generator also has an option to
+   generate old-definition keys, for the benefit of users who upgrade
+   their networks incrementally.
+
+6.8. Misc. Snags
+
+   Nonce size is another characteristic that is neither negotiated nor
+   announced but that the two ends must somehow be able to agree on.
+   Our software accepts anything between 8 and 256, and defaults to 16.
+   These numbers were chosen rather arbitrarily, but we have seen no
+
+
+
+Spencer & Redelmeier                                           [Page 18]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   interoperability failures here.
+
+   Nothing in the ISAKMP [ISAKMP] or IKE [IKE] specifications says
+   explicitly that a normal Message ID must be non-zero, but a zero
+   Message ID in fact causes failures.
+
+   Similarly, there is nothing in the specs which says that ISAKMP
+   cookies must be non-zero, but zero cookies will in fact cause
+   trouble.
+
+7. Security Considerations
+
+   Since this document discusses aspects of building robust and
+   interoperable IPsec implementations, security considerations permeate
+   it.
+
+8. References
+
+   [AH]       Kent, S., and Atkinson, R., "IP Authentication Header",
+              RFC 2402, Nov 1998.
+
+   [CIPHERS]  Pereira, R., and Adams, R., "The ESP CBC-Mode Cipher
+              Algorithms", RFC 2451, Nov 1998.
+
+   [CRACK]    Electronic Frontier Foundation, "Cracking DES: Secrets of
+              Encryption Research, Wiretap Politics and Chip Design",
+              O'Reilly 1998, ISBN 1-56592-520-3.
+
+   [DES]      Madson, C., and Doraswamy, N., "The ESP DES-CBC Cipher
+              Algorithm", RFC 2405, Nov 1998.
+
+   [DNSRSA]   D. Eastlake 3rd, "RSA/SHA-1 SIGs and RSA KEYs in the
+              Domain Name System (DNS)", RFC 3110, May 2001.
+
+   [ESP]      Kent, S., and Atkinson, R., "IP Encapsulating Security
+              Payload (ESP)", RFC 2406, Nov 1998.
+
+   [GROUPS]   Kivinen, T., and Kojo, M., "More MODP Diffie-Hellman
+              groups for IKE", <draft-ietf-ipsec-ike-modp-
+              groups-04.txt>, 13 Dec 2001 (work in progress).
+
+   [IKE]      Harkins, D., and Carrel, D., "The Internet Key Exchange
+              (IKE)", RFC 2409, Nov 1998.
+
+   [IPSEC]    Kent, S., and Atkinson, R., "Security Architecture for the
+              Internet Protocol", RFC 2401, Nov 1998.
+
+
+
+
+
+Spencer & Redelmeier                                           [Page 19]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   [ISAKMP]   Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
+              "Internet Security Association and Key Management Protocol
+              (ISAKMP)", RFC 2408, Nov 1998.
+
+   [OE]       Richardson, M., Redelmeier, D. H., and Spencer, H., "A
+              method for doing opportunistic encryption with IKE",
+              <draft-richardson-ipsec-opportunistic-06.txt>, 21 Feb 2002
+              (work in progress).
+
+   [PKCS1v1]  Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC
+              2313, March 1998.
+
+   [PKCS1v2]  Kaliski, B., and Staddon, J., "PKCS #1: RSA Cryptography
+              Specifications, Version 2.0", RFC 2437, Oct 1998.
+
+   [PFKEY]    McDonald, D., Metz, C., and Phan, B., "PF_KEY Key
+              Management API, Version 2", RFC 2367, July 1998.
+
+   [REKEY]    Tim Jenkins, "IPsec Re-keying Issues", <draft-jenkins-
+              ipsec-rekeying-06.txt>, 2 May 2000 (draft expired, work no
+              longer in progress).
+
+   [REPLAY]   Krywaniuk, A., "Using Isakmp Message Ids for Replay
+              Protection", <draft-krywaniuk-ipsec-antireplay-00.txt>, 9
+              July 2001 (work in progress).
+
+   [RSA]      Rivest, R.L., Shamir, A., and Adleman, L., "A Method for
+              Obtaining Digital Signatures and Public-Key
+              Cryptosystems", Communications of the ACM v21n2, Feb 1978,
+              p. 120.
+
+   [SCHNEIER] Bruce Schneier, "Applied Cryptography", 2nd ed., Wiley
+              1996, ISBN 0-471-11709-9.
+
+   [SECFAIL]  Karn, P., and Simpson, W., "ICMP Security Failures
+              Messages", RFC 2521, March 1999.
+
+Authors' Addresses
+
+   Henry Spencer
+   SP Systems
+   Box 280 Stn. A
+   Toronto, Ont. M5W1B2
+   Canada
+
+   henry@spsystems.net
+   416-690-6561
+
+
+
+
+Spencer & Redelmeier                                           [Page 20]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   D. Hugh Redelmeier
+   Mimosa Systems Inc.
+   29 Donino Ave.
+   Toronto, Ont. M4N2W6
+   Canada
+
+   hugh@mimosa.com
+   416-482-8253
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Spencer & Redelmeier                                           [Page 21]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society 2002. All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implmentation may be prepared, copied, published and
+   distributed, in whole or in part, without restriction of any kind,
+   provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the  purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Spencer & Redelmeier                                           [Page 22]
+
diff --git a/doc/src/draft-richardson-ipsec-opportunistic.html b/doc/src/draft-richardson-ipsec-opportunistic.html
new file mode 100644
index 000000000..87a13365a
--- /dev/null
+++ b/doc/src/draft-richardson-ipsec-opportunistic.html
@@ -0,0 +1,2456 @@
+<html><head><title>Opportunistic Encryption using The Internet Key Exchange (IKE)</title>
+<STYLE type='text/css'>
+    .title { color: #990000; font-size: 22px; line-height: 22px; font-weight: bold; text-align: right;
+             font-family: helvetica, arial, sans-serif }
+    .filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right;
+                  font-family: helvetica, arial, sans-serif }
+    p.copyright { color: #000000; font-size: 10px;
+                  font-family: verdana, charcoal, helvetica, arial, sans-serif }
+    p { margin-left: 2em; margin-right: 2em; }
+    li { margin-left: 3em;  }
+    ol { margin-left: 2em; margin-right: 2em; }
+    ul.text { margin-left: 2em; margin-right: 2em; }
+    pre { margin-left: 3em; color: #333333 }
+    ul.toc { color: #000000; line-height: 16px;
+             font-family: verdana, charcoal, helvetica, arial, sans-serif }
+    H3 { color: #333333; font-size: 16px; line-height: 16px; font-family: helvetica, arial, sans-serif }
+    H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, sans-serif }
+    TD.header { color: #ffffff; font-size: 10px; font-family: arial, helvetica, san-serif; valign: top }
+    TD.author-text { color: #000000; font-size: 10px;
+                     font-family: verdana, charcoal, helvetica, arial, sans-serif }
+    TD.author { color: #000000; font-weight: bold; margin-left: 4em; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif }
+     A:link { color: #990000; font-weight: bold;
+              font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
+     A:visited { color: #333333; font-weight: bold;
+                 font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
+     A:name { color: #333333; font-weight: bold;
+              font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
+    .link2 { color:#ffffff; font-weight: bold; text-decoration: none;
+             font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
+             font-size: 9px }
+    .RFC { color:#666666; font-weight: bold; text-decoration: none;
+           font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
+           font-size: 9px }
+    .hotText { color:#ffffff; font-weight: normal; text-decoration: none;
+               font-family: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
+               font-size: 9px }
+</style>
+</head>
+<body bgcolor="#ffffff" text="#000000" alink="#000000" vlink="#666666" link="#990000">
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<table width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table width="100%" border="0" cellpadding="2" cellspacing="1">
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Independent submission</td><td width="33%" bgcolor="#666666" class="header">M. Richardson</td></tr>
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Internet-Draft</td><td width="33%" bgcolor="#666666" class="header">SSW</td></tr>
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Expires: November 19, 2003</td><td width="33%" bgcolor="#666666" class="header">D. Redelmeier</td></tr>
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header">&nbsp;</td><td width="33%" bgcolor="#666666" class="header">Mimosa</td></tr>
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header">&nbsp;</td><td width="33%" bgcolor="#666666" class="header">May 21, 2003</td></tr>
+</table></td></tr></table>
+<div align="right"><font face="monaco, MS Sans Serif" color="#990000" size="+3"><b><br><span class="title">Opportunistic Encryption using The Internet Key Exchange (IKE)</span></b></font></div>
+<div align="right"><font face="monaco, MS Sans Serif" color="#666666" size="+2"><b><span class="filename">draft-richardson-ipsec-opportunistic-11.txt</span></b></font></div>
+<font face="verdana, helvetica, arial, sans-serif" size="2">
+
+<h3>Status of this Memo</h3>
+<p>
+This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.</p>
+<p>
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.
+Note that other groups may also distribute working documents as
+Internet-Drafts.</p>
+<p>
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any time.
+It is inappropriate to use Internet-Drafts as reference material or to cite
+them other than as "work in progress."</p>
+<p>
+The list of current Internet-Drafts can be accessed at
+<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
+<p>
+The list of Internet-Draft Shadow Directories can be accessed at
+<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
+<p>
+This Internet-Draft will expire on November 19, 2003.</p>
+
+<h3>Copyright Notice</h3>
+<p>
+Copyright (C) The Internet Society (2003). All Rights Reserved.</p>
+
+<h3>Abstract</h3>
+
+<p>
+This document describes opportunistic encryption (OE) using the Internet Key
+Exchange (IKE) and IPsec.  
+Each system administrator adds new
+resource records to his or her Domain Name System (DNS) to support
+opportunistic encryption. The objective is to allow encryption for secure communication without
+any pre-arrangement specific to the pair of systems involved.
+  
+</p>
+<p>
+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. 
+  
+</p>
+<p>
+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.
+  
+</p>
+<p>
+This document is offered up as an Informational RFC.
+  
+</p><a name="toc"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<h3>Table of Contents</h3>
+<ul compact class="toc">
+<b><a href="#anchor1">1.</a>&nbsp;
+Introduction<br></b>
+<b><a href="#anchor6">2.</a>&nbsp;
+Overview<br></b>
+<b><a href="#anchor13">3.</a>&nbsp;
+Specification<br></b>
+<b><a href="#anchor31">4.</a>&nbsp;
+Impacts on IKE<br></b>
+<b><a href="#anchor38">5.</a>&nbsp;
+DNS issues<br></b>
+<b><a href="#anchor42">6.</a>&nbsp;
+Network address translation interaction<br></b>
+<b><a href="#anchor46">7.</a>&nbsp;
+Host implementations<br></b>
+<b><a href="#anchor47">8.</a>&nbsp;
+Multi-homing<br></b>
+<b><a href="#anchor48">9.</a>&nbsp;
+Failure modes<br></b>
+<b><a href="#anchor52">10.</a>&nbsp;
+Unresolved issues<br></b>
+<b><a href="#anchor54">11.</a>&nbsp;
+Examples<br></b>
+<b><a href="#securityconsiderations">12.</a>&nbsp;
+Security considerations<br></b>
+<b><a href="#anchor79">13.</a>&nbsp;
+IANA Considerations<br></b>
+<b><a href="#anchor80">14.</a>&nbsp;
+Acknowledgments<br></b>
+<b><a href="#rfc.references1">&#167;</a>&nbsp;
+Normative references<br></b>
+<b><a href="#rfc.authors">&#167;</a>&nbsp;
+Authors' Addresses<br></b>
+<b><a href="#rfc.copyright">&#167;</a>&nbsp;
+Full Copyright Statement<br></b>
+</ul>
+<br clear="all">
+
+<a name="anchor1"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.1"></a><h3>1.&nbsp;Introduction</h3>
+
+<a name="rfc.section.1.1"></a><h4><a name="anchor2">1.1</a>&nbsp;Motivation</h4>
+
+<p>
+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.
+
+</p>
+<p>
+This document describes opportunistic encryption as designed and
+mostly implemented by the Linux FreeS/WAN project.
+For project information, see http://www.freeswan.org.
+
+</p>
+<p>
+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">[4]</a>.
+The Linux FreeS/WAN project attempts to provide a practical means to implement this policy. 
+  
+</p>
+<p>
+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. 
+  
+</p>
+<p>
+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.
+  
+</p>
+<p>
+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 - as 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.
+
+</p>
+<p>
+This document describes the infrastructure to permit deployment of
+Opportunistic Encryption.
+
+</p>
+<p>
+The term S/WAN is a trademark of RSA Data Systems, and is used with permission
+by this project.
+  
+</p>
+<a name="rfc.section.1.2"></a><h4><a name="anchor3">1.2</a>&nbsp;Types of network traffic</h4>
+
+<p>
+    To aid in understanding the relationship between security processing and IPsec
+    we divide network traffic into four categories:
+    
+<blockquote class="text"><dl>
+<dt>* Deny:</dt>
+<dd> networks to which traffic is always forbidden.
+</dd>
+<dt>* Permit:</dt>
+<dd> networks to which traffic in the clear is permitted.
+</dd>
+<dt>* Opportunistic tunnel:</dt>
+<dd> networks to which traffic is encrypted if possible, but otherwise is in the clear  
+	    or fails depending on the default policy in place.	
+      
+</dd>
+<dt>* Configured tunnel:</dt>
+<dd> networks to which traffic must be encrypted, and traffic in the clear is never permitted.
+</dd>
+</dl></blockquote><p>
+</p>
+<p>
+Traditional firewall devices handle the first two categories. No authentication is required.
+The permit policy is currently the default on the Internet. 
+
+</p>
+<p>
+This document describes the third category - opportunistic tunnel, which is
+proposed as the new default for the Internet.
+
+</p>
+<p>
+  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 a single authority, arranging for distribution of
+  authentication material, while difficult, does not require any new
+  technology. The mechanism described here provides an additional way to
+  distribute the authentication materials, that of a public key method that does not
+  require deployment of an X.509 based infrastructure.  
+
+</p>
+<p>
+Current Virtual Private Networks can often be replaced by an "OE paranoid"
+policy as described herein. 
+
+</p>
+<a name="rfc.section.1.3"></a><h4><a name="anchor4">1.3</a>&nbsp;Peer authentication in opportunistic encryption</h4>
+
+<p>
+  Opportunistic encryption creates tunnels between nodes that
+  are essentially strangers. This is done without any prior bilateral
+  arrangement. 
+  There is, therefore, the difficult question of how one knows to whom one is
+  talking.
+  
+</p>
+<p>
+  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.
+  
+</p>
+<p>
+Although 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 desireable goal.
+The latter is achieved through key distribution in DNS, leveraging upon
+the authentication of the DNS in DNSSEC.
+
+</p>
+<p>
+  Peers are, therefore, authenticated with DNSSEC when available. Local policy 
+determines how much trust to extend when DNSSEC is not available.
+  
+</p>
+<p>
+  However, 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.
+  
+</p>
+<p>
+  When initiating outbound opportunistic encryption, local 
+  configuration determines what happens if tunnel setup fails. It may be that
+  the packet goes out in the clear, or it may be dropped.
+  
+</p>
+<a name="rfc.section.1.4"></a><h4><a name="anchor5">1.4</a>&nbsp;Use of RFC2119 terms</h4>
+
+<p>
+   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">[5]</a>
+</p>
+<a name="anchor6"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.2"></a><h3>2.&nbsp;Overview</h3>
+
+<a name="rfc.section.2.1"></a><h4><a name="anchor7">2.1</a>&nbsp;Reference diagram</h4>
+<br><hr size="1" shade="0">
+<a name="networkdiagram"></a>
+
+<p>The following network diagram is used in the rest of
+		this document as the canonical diagram:
+</p></font><pre>
+                          [Q]  [R]          
+                           .    .              AS2                 
+  [A]----+----[SG-A].......+....+.......[SG-B]-------[B]
+         |                 ......
+     AS1 |                 ..PI..
+         |                 ......
+  [D]----+----[SG-D].......+....+.......[C] AS3
+             
+
+           </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+
+<p>
+</p><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Reference Network Diagram&nbsp;</b></font><br></td></tr></table><hr size="1" shade="0">
+
+<p>
+    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, AS1. SG-A and SG-D are on two different exit
+    paths from organization 1. SG-B/B is an independent organization, AS2.
+    Nodes Q and R are nodes on the Internet. PI is the Public
+    Internet ("The Wild").
+    
+</p>
+<a name="rfc.section.2.2"></a><h4><a name="anchor8">2.2</a>&nbsp;Terminology</h4>
+
+<p>
+  The following terminology is used in this document:
+  
+</p>
+<blockquote class="text"><dl>
+<dt>Security gateway:</dt>
+<dd> a system that performs IPsec tunnel
+    mode encapsulation/decapsulation. [SG-x] in the diagram.
+</dd>
+<dt>Alice:</dt>
+<dd> node [A] in the diagram. When an IP address is needed, this is 192.1.0.65.
+</dd>
+<dt>Bob:</dt>
+<dd> node [B] in the diagram. When an IP address is needed, this is 192.2.0.66.
+</dd>
+<dt>Carol:</dt>
+<dd> node [C] in the diagram. When an IP address is needed, this is 192.1.1.67.
+</dd>
+<dt>Dave:</dt>
+<dd> node [D] in the diagram. When an IP address is needed, this is 192.3.0.68.
+</dd>
+<dt>SG-A:</dt>
+<dd> Alice's security gateway. Internally it is 192.1.0.1, externally it is 192.1.1.4.
+</dd>
+<dt>SG-B:</dt>
+<dd> Bob's security gateway. Internally it is 192.2.0.1, externally it is 192.1.1.5.
+</dd>
+<dt>SG-D:</dt>
+<dd> Dave's security gateway. Also Alice's backup security gateway. Internally it is 192.3.0.1, externally it is 192.1.1.6.
+</dd>
+<dt>-</dt>
+<dd> A single dash represents clear-text datagrams.
+</dd>
+<dt>=</dt>
+<dd> An equals sign represents phase 2 (IPsec) cipher-text
+        datagrams.
+</dd>
+<dt>~</dt>
+<dd> A single tilde represents clear-text phase 1 datagrams.
+</dd>
+<dt>#</dt>
+<dd> A hash sign represents phase 1 (IKE) cipher-text
+        datagrams.
+</dd>
+<dt>.</dt>
+<dd> A period represents an untrusted network of unknown
+        type.
+</dd>
+<dt>Configured tunnel:</dt>
+<dd> 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.
+</dd>
+<dt>Road warrior tunnel:</dt>
+<dd> 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. 
+</dd>
+<dt>Anonymous encryption:</dt>
+<dd>
+	the process of encrypting a session without any knowledge of who the
+	other parties are. No authentication of identities is done.
+</dd>
+<dt>Opportunistic encryption:</dt>
+<dd>
+	the process of encrypting a session with authenticated knowledge of
+	who the other parties are.
+</dd>
+<dt>Lifetime:</dt>
+<dd>
+        the period in seconds (bytes or datagrams) for which a security
+	association will remain alive before needing to be re-keyed.
+</dd>
+<dt>Lifespan:</dt>
+<dd>
+        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.
+</dd>
+<dt>Phase 1 SA:</dt>
+<dd> an ISAKMP/IKE security association sometimes
+      referred to as a keying channel.
+</dd>
+<dt>Phase 2 SA:</dt>
+<dd> an IPsec security association.
+</dd>
+<dt>Tunnel:</dt>
+<dd> another term for a set of phase 2 SA (one in each direction).
+</dd>
+<dt>NAT:</dt>
+<dd> Network Address Translation
+    (see <a href="#RFC2663">[20]</a>).
+</dd>
+<dt>NAPT:</dt>
+<dd> Network Address and Port Translation
+    (see <a href="#RFC2663">[20]</a>).
+</dd>
+<dt>AS:</dt>
+<dd> an autonomous system (AS) is a group of systems (a network) that
+		are under the administrative control of a single organization.
+</dd>
+<dt>Default-free zone:</dt>
+<dd> 
+    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.
+    
+</dd>
+</dl></blockquote><p>
+<a name="rfc.section.2.3"></a><h4><a name="anchor9">2.3</a>&nbsp;Model of operation</h4>
+
+<p>
+The opportunistic encryption security gateway (OE gateway) is a regular
+gateway node as described in <a href="#RFC0791">[2]</a> section 2.4 and  
+<a href="#RFC1009">[3]</a> with the additional capabilities described here and
+in <a href="#RFC2401">[7]</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 end point which should be used. 
+
+</p>
+<a name="rfc.section.2.3.1"></a><h4><a name="anchor10">2.3.1</a>&nbsp;Tunnel authorization</h4>
+
+<p>
+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="#TXT">Use of TXT delegation record</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.
+
+</p>
+<a name="rfc.section.2.3.2"></a><h4><a name="anchor11">2.3.2</a>&nbsp;Tunnel end-point discovery</h4>
+
+<p>
+The authorization resource record also provides the address or name of the tunnel
+end point which should be used.
+
+</p>
+<p>
+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 end point address or name.
+
+</p>
+<p>
+Origin and integrity protection of the resource records is provided by 
+DNSSEC (<a href="#RFC2535">[16]</a>). <a href="#nodnssec">Restriction on unauthenticated TXT delegation records</a>
+documents an optional restriction on the tunnel end point if DNSSEC signatures
+are not available for the relevant records. 
+
+</p>
+<a name="rfc.section.2.3.3"></a><h4><a name="anchor12">2.3.3</a>&nbsp;Caching of authorization results</h4>
+
+<p>
+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. 
+
+</p>
+<p>
+Successful negotiation of OE instantiates a new security association. 
+Failure to negotiate OE results in creation of a 
+forwarding policy entry either to drop or transmit in the clear future
+datagrams. This negative cache is necessary to avoid the possibly lengthy process of repeatedly looking 
+up the same information.
+
+</p>
+<p>
+The cache is timed out periodically, as described in <a href="#teardown">Renewal and teardown</a>.
+This removes entries that are no longer
+being used and permits the discovery of changes in authorization policy.
+
+</p>
+<a name="anchor13"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.3"></a><h3>3.&nbsp;Specification</h3>
+
+<p>
+The OE gateway is modeled to have a forwarding plane and a control
+plane. A control channel, such as PF_KEY, connects the two planes. 
+(See <a href="#RFC2367">[6]</a>.)
+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.  
+
+</p>
+<a name="rfc.section.3.1"></a><h4><a name="anchor14">3.1</a>&nbsp;Datagram state machine</h4>
+
+<p>
+Let the OE gateway maintain a collection of objects -- a superset of the
+security policy database (SPD) specified in <a href="#RFC2401">[7]</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.
+
+</p>
+<a name="rfc.section.3.1.1"></a><h4><a name="anchor15">3.1.1</a>&nbsp;Non-existent policy</h4>
+
+<p>
+If the responder does not find an entry, then this policy applies.
+The responder creates an entry with an initial state of "hold policy" and requests 
+keying material from the keying daemon. The responder does not forward the datagram,
+rather it attaches the datagram to the SPD entry as the  "first" datagram and retains it
+for eventual transmission in a new state. 
+
+
+</p>
+<a name="rfc.section.3.1.2"></a><h4><a name="anchor16">3.1.2</a>&nbsp;Hold policy</h4>
+
+<p>
+The responder 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 responder does not forward the datagram. It attaches the 
+datagram to the SPD entry as the "last" datagram where it is retained 
+for eventual transmission. If there is
+a datagram already so stored, then that already stored datagram is discarded.
+
+</p>
+<p>
+Because the "first" datagram is probably a TCP SYN packet, the 
+responder retains the "first" datagram in an attempt to avoid waiting for a
+TCP retransmit. The responder retains the "last"
+datagram in deference to streaming protocols that find it useful to know
+how much data has been lost. These are recommendations to 
+decrease latency. There are no operational requirements for this.
+
+</p>
+<a name="rfc.section.3.1.3"></a><h4><a name="anchor17">3.1.3</a>&nbsp;Pass-through policy</h4>
+
+<p>
+The responder forwards the datagram using the normal forwarding table. 
+The responder enters this state only by command from the keying daemon, 
+and upon entering this state, also forwards the "first" and "last" datagrams.
+
+</p>
+<a name="rfc.section.3.1.4"></a><h4><a name="anchor18">3.1.4</a>&nbsp;Deny policy</h4>
+
+<p>
+The responder discards the datagram. The responder enters this state only by
+command  
+from the keying daemon, and upon entering this state, discards the "first"
+and "last" datagrams.  
+Local administration decides if further datagrams cause ICMP messages
+to be generated (i.e. ICMP Destination Unreachable, Communication
+Administratively Prohibited. type=3, code=13). 
+
+</p>
+<a name="rfc.section.3.1.5"></a><h4><a name="anchor19">3.1.5</a>&nbsp;Encrypt policy</h4>
+
+<p>
+The responder encrypts the datagram using the indicated security association database
+(SAD) entry.  The responder 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.  
+
+</p>
+<p>
+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.
+
+</p>
+<p>
+All states may be created directly by the keying daemon while acting as a
+responder. 
+
+</p>
+<a name="rfc.section.3.2"></a><h4><a name="initclasses">3.2</a>&nbsp;Keying state machine - initiator</h4>
+
+<p>
+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 - what could be. An instance represents an actual connection -  
+what is implemented at the time.
+
+</p>
+<p>
+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.
+
+</p>
+<p>
+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 source and/or destination
+addresses 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.
+
+</p>
+<p>
+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. 
+
+</p>
+<p>
+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.
+
+</p>
+<p>
+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">[8]</a>, 
+<a href="#RFC2408">[9]</a> and <a href="#RFC2409">[10]</a> 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 that implementations inter-operate.
+
+</p>
+<p>
+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.
+
+</p>
+<p>
+Finally, the retransmits and recursive lookups that are normal for DNS are 
+not included in this description of the state machine.
+
+</p>
+<a name="rfc.section.3.2.1"></a><h4><a name="anchor20">3.2.1</a>&nbsp;Nonexistent connection</h4>
+
+<p>
+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.
+
+</p>
+<p>Failure to find an appropriate connection class results in an
+administrator defined default. 
+
+</p>
+<p>
+In each case, when the initiator finds an appropriate class for the new flow, 
+an instance connection is made of the class which matched.
+
+</p>
+<a name="rfc.section.3.2.2"></a><h4><a name="anchor21">3.2.2</a>&nbsp;Clear-text connection</h4>
+
+<p>
+The non-existent 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.
+
+</p>
+<p>
+Timing out is the only way to leave this state
+(see <a href="#expiring">Expiring connection</a>).
+
+</p>
+<a name="rfc.section.3.2.3"></a><h4><a name="anchor22">3.2.3</a>&nbsp;Deny connection</h4>
+
+<p>
+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.  
+
+</p>
+<p>
+Timing out is the only way to leave this state 
+(see <a href="#expiring">Expiring connection</a>).
+
+</p>
+<a name="rfc.section.3.2.4"></a><h4><a name="anchor23">3.2.4</a>&nbsp;Potential OE connection</h4>
+
+<p>
+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.  
+
+</p>
+<p>
+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="#TXT">Use of TXT delegation record</a>).
+The lookup key is the destination address of the flow.
+
+</p>
+<p>
+There are three ways to exit this state: 
+
+<ol class="text">
+<li>DNS lookup finds a TXT delegation resource record.
+</li>
+<li>DNS lookup does not find a TXT delegation resource record.
+</li>
+<li>DNS lookup times out.
+</li>
+</ol><p>
+</p>
+<p>
+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:
+
+<ol class="text">
+<li>DNS finds an appropriate resource record
+</li>
+<li>It is properly formatted according to <a href="#TXT">Use of TXT delegation record</a>
+</li>
+<li> if DNSSEC is enabled, then the signature has been vouched for.
+</li>
+</ol><p>
+
+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.
+
+</p>
+<p>
+If DNS lookup does not find a resource record or 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.
+
+</p>
+<p>
+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 should make 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.
+
+</p>
+<a name="rfc.section.3.2.4.1"></a><h4><a name="nodnssec">3.2.4.1</a>&nbsp;Restriction on unauthenticated TXT delegation records</h4>
+
+<p>
+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.
+
+</p>
+<a name="rfc.section.3.2.5"></a><h4><a name="anchor24">3.2.5</a>&nbsp;Pending OE connection</h4>
+
+<p>
+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.  
+
+</p>
+<p>
+Exit from this state occurs 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.
+
+</p>
+<p>
+Three failures have caused significant problems. They are clearly not the
+only possible failures from keying.
+
+</p>
+<p>
+Note that if there are 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.
+
+</p>
+<p>
+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. 
+
+</p>
+<p>
+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.
+
+</p>
+<p>
+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. 
+
+</p>
+<p>
+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 than non-signed records.) 
+
+</p>
+<a name="rfc.section.3.2.6"></a><h4><a name="keyed">3.2.6</a>&nbsp;Keyed connection</h4>
+
+<p>
+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.
+
+</p>
+<p>
+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.
+
+</p>
+<p>
+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 to use 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.
+
+</p>
+<p>
+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. 
+
+</p>
+<a name="rfc.section.3.2.7"></a><h4><a name="expiring">3.2.7</a>&nbsp;Expiring connection</h4>
+
+<p>
+The initiator will periodically place each of the deny, clear-text, and keyed
+connections into this  
+sub-state. See <a href="#teardown">Renewal and teardown</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. 
+
+</p>
+<p>
+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">[12]</a> section 4.3.4.)
+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.
+
+</p>
+<p> 
+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.
+
+</p>
+<p>
+Also note that the policy at the forwarding plane is not updated unless there
+is a conclusion that there should be a change.
+
+</p>
+<a name="rfc.section.3.2.8"></a><h4><a name="anchor25">3.2.8</a>&nbsp;Expired connection</h4>
+
+<p>
+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. 
+
+</p>
+<p>
+The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs as described in
+<a href="#teardown">Renewal and teardown</a>. 
+
+</p>
+<p>
+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.
+
+</p>
+<a name="rfc.section.3.3"></a><h4><a name="anchor26">3.3</a>&nbsp;Keying state machine - responder</h4>
+
+<p>
+The responder has a set of objects identical to those of the initiator.
+
+</p>
+<p>
+The responder receives an invitation to create a keying channel from an initiator. 
+
+</p>
+<a name="rfc.section.3.3.1"></a><h4><a name="anchor27">3.3.1</a>&nbsp;Unauthenticated OE peer</h4>
+
+<p>
+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">[8]</a> section 
+4.6.2.1.)
+
+</p>
+<p>
+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.
+
+</p>
+<p>
+Successful authentication of the peer results in a transition to the
+authenticated OE Peer state.
+
+</p>
+<p>
+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.
+
+</p>
+<a name="rfc.section.3.3.2"></a><h4><a name="anchor28">3.3.2</a>&nbsp;Authenticated OE Peer</h4>
+
+<p>
+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. 
+
+</p>
+<p> 
+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.
+
+</p>
+<p> 
+If an identical connection is not found, then the responder makes the transition according to the 
+rules given for the initiator.
+
+</p>
+<p> 
+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.
+ 
+</p>
+<a name="rfc.section.3.4"></a><h4><a name="teardown">3.4</a>&nbsp;Renewal and teardown</h4>
+
+<a name="rfc.section.3.4.1"></a><h4><a name="anchor29">3.4.1</a>&nbsp;Aging</h4>
+
+<p>
+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.
+
+</p>
+<p>
+There are two methods for removing tunnels: explicit deletion or expiry. 
+
+</p>
+<p>
+Explicit deletion requires an IKE delete message. As the deletes
+MUST be authenticated, both ends of the tunnel must maintain the 
+key channel (phase 1 ISAKMP SA). An implementation which refuses to either maintain or
+recreate the keying channel SA will be unable to use this method.
+
+</p>
+<p>
+The tunnel expiry method, simply allows the IKE daemon to
+expire normally without attempting to re-key it.
+
+</p>
+<p>
+Regardless of which method is used to remove tunnels, the implementation requires 
+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.
+
+</p>
+<p>
+Set a short initial (soft) lifespan of 1 minute since many net flows last
+only a few seconds.
+
+</p>
+<p>
+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.
+
+</p>
+<p>
+The expiring state in the key management
+system (see <a href="#expiring">Expiring connection</a>) implements these timeouts.
+The timer above may be in the forwarding plane, 
+but then it must be re-settable. 
+
+</p>
+<p>
+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.
+
+</p>
+<p>
+A multi-step back-off algorithm is not considered worth the effort here.
+
+</p>
+<p>
+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.
+
+</p>
+<a name="rfc.section.3.4.2"></a><h4><a name="anchor30">3.4.2</a>&nbsp;Teardown and cleanup</h4>
+
+<p>
+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.
+
+</p>
+<p>
+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 which 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. 
+
+</p>
+<p>
+Tunnels are to be considered as bidirectional entities, even though the
+low-level protocols don't treat them this way. 
+
+</p>
+<p>
+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.)
+
+</p>
+<p>
+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 outgoing SAs) rather than waiting for them to expire. This
+reduces clutter and minimizes confusion for the operator doing diagnostics.
+
+</p>
+<a name="anchor31"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.4"></a><h3>4.&nbsp;Impacts on IKE</h3>
+
+<a name="rfc.section.4.1"></a><h4><a name="anchor32">4.1</a>&nbsp;ISAKMP/IKE protocol</h4>
+
+<p>
+    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.
+    
+</p>
+<p>
+    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. 
+    
+</p>
+<p>
+    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.
+    
+</p>
+<a name="rfc.section.4.2"></a><h4><a name="anchor33">4.2</a>&nbsp;Gateway discovery process</h4>
+
+<p>
+  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.
+  
+</p>
+<p>
+  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. 
+  
+</p>
+<p> 
+  Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with
+  some of the protocol steps.
+  
+</p>
+<a name="rfc.section.4.3"></a><h4><a name="anchor34">4.3</a>&nbsp;Self identification</h4>
+
+<p>
+     SG-A will have to establish its identity. Use an
+     IPv4 ID in phase 1. 
+  
+</p>
+<p> 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) 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="#fqdn">Use of FQDN IDs</a>
+      for more details and restrictions.
+  
+</p>
+<a name="rfc.section.4.4"></a><h4><a name="anchor35">4.4</a>&nbsp;Public key retrieval process</h4>
+
+<p>
+     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.
+  
+</p>
+<p> 
+     It is reasonable that if other non-local sources of policy are used
+     (COPS, LDAP), they be consulted concurrently but 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.
+  
+</p>
+<a name="rfc.section.4.5"></a><h4><a name="anchor36">4.5</a>&nbsp;Interactions with DNSSEC</h4>
+
+<p>
+     The implementation described (1.98) neither uses DNSSEC directly to
+     explicitly verify the authenticity of zone information, nor uses the NXT
+     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. 
+  
+</p>
+<p> 
+     To distinguish between an authenticated and an unauthenticated DNS
+     resource record, a stub resolver capable of returning DNSSEC
+     information MUST be used.
+  
+</p>
+<a name="rfc.section.4.6"></a><h4><a name="anchor37">4.6</a>&nbsp;Required proposal types</h4>
+
+<a name="rfc.section.4.6.1"></a><h4><a name="phase1id">4.6.1</a>&nbsp;Phase 1 parameters</h4>
+
+<p>
+        Main mode MUST be used.
+      
+</p>
+<p>
+	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.
+	<a href="#RFC3526">[11]</a>
+</p>
+<p>
+	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.
+      
+</p>
+<p>
+	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. 
+      
+</p>
+<p>
+        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 <a href="#fqdn">Use of FQDN IDs</a>.) The authentication method MUST be RSA public key signatures. 
+        The RSA key for SG-A SHOULD be placed into a DNS KEY record in
+	the reverse space of SG-A (i.e. using in-addr.arpa).
+      
+</p>
+<a name="rfc.section.4.6.2"></a><h4><a name="phase2id">4.6.2</a>&nbsp;Phase 2 parameters</h4>
+
+<p>
+        SG-A MUST propose a tunnel between Alice and Bob, using 3DES-CBC
+        mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be specified.
+      
+</p>
+<p>
+        Tunnel mode MUST be used.
+      
+</p>
+<p>
+        Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32.
+      
+</p>
+<p>
+        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.
+      
+</p>
+<p>
+        Compression SHOULD NOT be mandatory. It may be offered as an option.
+      
+</p>
+<a name="anchor38"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.5"></a><h3>5.&nbsp;DNS issues</h3>
+
+<a name="rfc.section.5.1"></a><h4><a name="KEY">5.1</a>&nbsp;Use of KEY record</h4>
+
+<p>
+    In order to establish their own identities, SG-A and SG-B SHOULD publish
+    their public keys in their reverse DNS via 
+    DNSSEC's KEY record.
+    See section 3 of <a href="#RFC2535">RFC 2535</a>[16].
+  
+</p>
+<p>
+<p>For example:
+</p></font><pre>
+KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+
+<blockquote class="text"><dl>
+<dt>0x4200:</dt>
+<dd> 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.
+</dd>
+<dt>4:</dt>
+<dd>This indicates that this key is for use by IPsec.
+</dd>
+<dt>1:</dt>
+<dd>An RSA key is present.
+</dd>
+<dt>AQNJjkKlIk9...nYyUkKK8:</dt>
+<dd>The public key of the host as described in <a href="#RFC3110">[17]</a>.
+</dd>
+</dl></blockquote><p>
+</p>
+<p>Use of several KEY records allows for key rollover. The SIG Payload in
+  IKE phase 1 SHOULD be accepted if the public key given by any KEY RR
+  validates it.
+  
+</p>
+<a name="rfc.section.5.2"></a><h4><a name="TXT">5.2</a>&nbsp;Use of TXT delegation record</h4>
+
+<p>
+Alice publishes a TXT record to provide authorization for SG-A to act on
+Alice's behalf. 
+
+Bob publishes a TXT record to provide authorization for SG-B to act on Bob's
+behalf.  
+
+These records are located in the reverse DNS (in-addr.arpa) for their
+respective IP addresses.  The reverse DNS SHOULD be secured by DNSSEC, when
+it is deployed. DNSSEC is required to defend against active attacks.
+    
+</p>
+<p>
+      If Alice's address is P.Q.R.S, then she can authorize another node to
+      act on her behalf by publishing records at:
+           </p>
+</font><pre>
+S.R.Q.P.in-addr.arpa
+          </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<p>
+
+</p>
+<p>
+    The contents of the resource record are expected to be a string that
+    uses the following syntax, as suggested in <a href="#RFC1464">[15]</a>.
+    (Note that the reply to query may include other TXT resource
+    records used by other applications.)
+
+    <br><hr size="1" shade="0">
+<a name="txtformat"></a>
+</p>
+</font><pre>
+X-IPsec-Server(P)=A.B.C.D KEY
+          </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<p>
+<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Format of reverse delegation record&nbsp;</b></font><br></td></tr></table><hr size="1" shade="0">
+
+</p>
+<blockquote class="text"><dl>
+<dt>P:</dt>
+<dd> Specifies a precedence for this record.  This is
+      similar to MX record preferences.  Lower numbers have stronger
+      preference. 
+      
+</dd>
+<dt>A.B.C.D:</dt>
+<dd> Specifies the IP address of the Security Gateway
+      for this client machine.
+      
+</dd>
+<dt>KEY:</dt>
+<dd> Is the encoded RSA Public key of the Security
+      Gateway. The 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.
+      
+</dd>
+</dl></blockquote><p>
+<p>
+  	The pieces of the record are separated by any whitespace
+	(space, tab, newline, carriage return). An ASCII space SHOULD
+	be used.
+    
+</p>
+<p>
+	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.
+
+    <br><hr size="1" shade="0">
+<a name="txtfqdnformat"></a>
+</p>
+</font><pre>
+X-IPsec-Server(P)=@FQDN KEY
+          </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<p>
+<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Format of reverse delegation record (FQDN version)&nbsp;</b></font><br></td></tr></table><hr size="1" shade="0">
+
+</p>
+<blockquote class="text"><dl>
+<dt>P:</dt>
+<dd> Is as above.
+      
+</dd>
+<dt>FQDN:</dt>
+<dd> Specifies the FQDN that the Security Gateway
+      will identify itself with. 
+      
+</dd>
+<dt>KEY:</dt>
+<dd> Is the encoded RSA Public key of the Security
+      Gateway. 
+</dd>
+</dl></blockquote><p>
+<p>
+	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. 
+    
+</p>
+<a name="rfc.section.5.2.1"></a><h4><a name="anchor39">5.2.1</a>&nbsp;Long TXT records</h4>
+
+<p>
+  When packed into transport format, TXT records which are longer than 255
+  characters are divided into smaller &lt;character-strings&gt;.
+  (See <a href="#RFC1035">[13]</a> section 3.3 and 3.3.14.) These MUST
+  be reassembled into a single string for processing.
+  Whitespace characters in the base64 encoding are to be ignored.
+  
+</p>
+<a name="rfc.section.5.2.2"></a><h4><a name="anchor40">5.2.2</a>&nbsp;Choice of TXT record</h4>
+
+<p>
+	It has been suggested to use the KEY, OPT, CERT, or KX records
+	instead of a TXT record. None is satisfactory.
+  
+</p>
+<p> The KEY RR has a protocol field which could be used to indicate a new protocol, 
+and an algorithm field which 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.
+  
+</p>
+<p> OPT resource records, as defined in <a href="#RFC2671">[14]</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.
+  
+</p>
+<p>
+    CERT records <a href="#RFC2538">[18]</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.
+  
+</p>
+<p>
+    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.
+  
+</p>
+<p>
+    KX records are ideally suited for use instead of TXT records, but had not been deployed at
+    the time of implementation.
+
+</p>
+<a name="rfc.section.5.3"></a><h4><a name="fqdn">5.3</a>&nbsp;Use of FQDN IDs</h4>
+
+<p>
+      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.
+    
+</p>
+<p>
+      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. 
+    
+</p>
+<p>
+      This method can also be used when the external address of SG-A is
+      dynamic. 
+    
+</p>
+<p>
+      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. 
+</p>
+<p>However, Alice must still delegate to  herself if she wishes others to
+       initiate OE to her.  See <a href="#txtfqdnformat">Format of reverse delegation record (FQDN version)</a>.
+    
+</p>
+<a name="rfc.section.5.4"></a><h4><a name="anchor41">5.4</a>&nbsp;Key roll-over</h4>
+
+<p>
+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 it propagating through DNS.
+
+</p>
+<p>
+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 in additional TXT
+delegation records) at key generation time. Note: only one key is allowed in
+each TXT record.
+
+</p>
+<p>
+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.
+
+</p>
+<a name="anchor42"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.6"></a><h3>6.&nbsp;Network address translation interaction</h3>
+
+<p>
+     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.
+  
+</p>
+<p>
+     There are several situations to consider for NAT.
+  
+</p>
+<a name="rfc.section.6.1"></a><h4><a name="anchor43">6.1</a>&nbsp;Co-located NAT/NAPT</h4>
+
+<p>
+       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
+       typically configured tunnels 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 up that address to
+       confirm SG-A's authorization. 
+    
+</p>
+<p> 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.
+    
+</p>
+<p> 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 to 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.
+    
+</p>
+<a name="rfc.section.6.2"></a><h4><a name="anchor44">6.2</a>&nbsp;SG-A behind NAT/NAPT</h4>
+
+<p>
+       If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec
+       NAT traversal rules apply. 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 SG-A, there is no appropriate ID for phase 2
+	that permits SG-B to determine that SG-A is in fact authorized to speak for Alice. 
+    
+</p>
+<a name="rfc.section.6.3"></a><h4><a name="anchor45">6.3</a>&nbsp;Bob is behind a NAT/NAPT</h4>
+
+<p>
+       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. This creates an asymmetry, but this is common for 
+       NAPT.
+    
+</p>
+<a name="anchor46"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.7"></a><h3>7.&nbsp;Host implementations</h3>
+
+<p>
+  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.
+
+</p>
+<p>
+  Components marked Alice are the upper layers (TCP, UDP, the
+  application), and SG-A is the IP layer.
+
+</p>
+<p>
+  Note that tunnel mode is still required. 
+
+</p>
+<p>
+  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.
+
+</p>
+<a name="anchor47"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.8"></a><h3>8.&nbsp;Multi-homing</h3>
+
+<p> 
+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. 
+
+</p>
+<p>
+In <a href="#networkdiagram">Reference Network Diagram</a>, 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.
+
+</p>
+<p>
+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. 
+
+</p>
+<p>
+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:
+    <br><hr size="1" shade="0">
+<a name="txtmultiexample"></a>
+</p>
+</font><pre>
+X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
+X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
+          </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<p>
+<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Multiple gateway delegation example for Alice&nbsp;</b></font><br></td></tr></table><hr size="1" shade="0">
+
+</p>
+<p>
+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. 
+
+</p>
+<p>
+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. 
+
+</p>
+<p>
+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.  
+
+</p>
+<p>
+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.
+
+</p>
+<p>
+SG-B may make a number of choices:
+
+<ol class="text">
+<li>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.
+</li>
+<li>It can send to the gateway from which it most recently received datagrams. 
+      This assumes that routing and reachability are symmetrical.
+</li>
+<li>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. 
+</li>
+<li>It can refuse to negotiate the second tunnel. (It is unclear whether or
+not this is even an option.)
+</li>
+<li>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, accept datagrams from either SG-A or SG-D, but
+send only to the gateway that most recently re-keyed with it.
+</li>
+</ol><p>
+</p>
+<p>
+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. 
+
+</p>
+<p>
+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.
+
+</p>
+<a name="anchor48"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.9"></a><h3>9.&nbsp;Failure modes</h3>
+
+<a name="rfc.section.9.1"></a><h4><a name="anchor49">9.1</a>&nbsp;DNS failures</h4>
+
+<p>
+  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="#initclasses">Keying state machine - initiator</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.
+  
+</p>
+<p>
+  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.
+  
+</p>
+<a name="rfc.section.9.2"></a><h4><a name="anchor50">9.2</a>&nbsp;DNS configured, IKE failures</h4>
+
+<p>
+  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.  
+  
+</p>
+<p>
+  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.
+  
+</p>
+<p>
+  In these situations a clear log should be produced
+  and local policy should dictate if communication is then
+  permitted in the clear.
+  
+</p>
+<a name="rfc.section.9.3"></a><h4><a name="anchor51">9.3</a>&nbsp;System reboots</h4>
+
+<p>
+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.
+
+</p>
+<p>
+A mechanism for recovery after reboot is a topic of current research and is not specified in this
+document.
+
+</p>
+<p>
+A deliberate shutdown should include an attempt, using deletes, 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.
+
+</p>
+<a name="anchor52"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.10"></a><h3>10.&nbsp;Unresolved issues</h3>
+
+<a name="rfc.section.10.1"></a><h4><a name="anchor53">10.1</a>&nbsp;Control of reverse DNS</h4>
+
+<p>
+  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.
+  
+</p>
+<a name="anchor54"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.11"></a><h3>11.&nbsp;Examples</h3>
+
+<a name="rfc.section.11.1"></a><h4><a name="anchor55">11.1</a>&nbsp;Clear-text usage (permit policy)</h4>
+
+<p>
+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.
+
+</p><br><hr size="1" shade="0">
+<a name="regulartiming"></a>
+</font><pre>
+  Alice         SG-A       DNS       SG-B           Bob
+   (1)
+    ------(2)-------------->
+    &lt;-----(3)---------------
+   (4)----(5)----->
+                   ----------(6)------>
+                                       ------(7)----->
+                                      &lt;------(8)------
+                   &lt;----------(9)------
+    &lt;----(10)-----
+   (11)----------->
+                   ----------(12)----->
+                                       -------------->
+                                      &lt;---------------
+                   &lt;-------------------
+    &lt;-------------
+          </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Timing of regular transaction&nbsp;</b></font><br></td></tr></table><hr size="1" shade="0">
+
+<p>
+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: 
+
+<blockquote class="text"><dl>
+<dt>(1)</dt>
+<dd>Human or application 'clicks' with a name.
+</dd>
+<dt>(2)</dt>
+<dd>Application looks up name in DNS to get IP address.
+</dd>
+<dt>(3)</dt>
+<dd>Resolver returns A record to application.
+</dd>
+<dt>(4)</dt>
+<dd>Application starts a TCP session or UDP session and OS sends datagram.
+</dd>
+<dt>(5)</dt>
+<dd>Datagram is seen at first gateway from Alice (SG-A). (SG-A
+makes a transition through Empty connection to always-clear connection and
+instantiates a pass-through policy at the forwarding plane.)
+</dd>
+<dt>(6)</dt>
+<dd>Datagram is seen at last gateway before Bob (SG-B).
+</dd>
+<dt>(7)</dt>
+<dd>First datagram from Alice is seen by Bob.
+</dd>
+<dt>(8)</dt>
+<dd>First return datagram is sent by Bob.
+</dd>
+<dt>(9)</dt>
+<dd>Datagram is seen at Bob's gateway. (SG-B makes a transition through
+Empty connection to always-clear connection and instantiates a pass-through
+policy at the forwarding plane.)
+</dd>
+<dt>(10)</dt>
+<dd>Datagram is seen at Alice's gateway.
+</dd>
+<dt>(11)</dt>
+<dd>OS hands datagram to application. Alice sends another datagram.
+</dd>
+<dt>(12)</dt>
+<dd>A second datagram traverses the Internet.
+</dd>
+</dl></blockquote><p>
+</p>
+<a name="rfc.section.11.2"></a><h4><a name="anchor56">11.2</a>&nbsp;Opportunistic encryption</h4>
+
+<p>
+In the presence of properly configured opportunistic encryptors, the
+event list is extended.
+
+<br><hr size="1" shade="0">
+<a name="opportunistictiming"></a>
+</p>
+</font><pre>
+  Alice          SG-A      DNS       SG-B           Bob
+   (1)
+    ------(2)-------------->
+    &lt;-----(3)---------------
+   (4)----(5)----->+
+                  ----(5B)->
+                  &lt;---(5C)--
+                  ~~~~~~~~~~~~~(5D)~~~>
+                  &lt;~~~~~~~~~~~~(5E1)~~~
+                  ~~~~~~~~~~~~~(5E2)~~>
+                  &lt;~~~~~~~~~~~~(5E3)~~~
+                  #############(5E4)##>
+                  &lt;############(5E5)###
+                           &lt;----(5F1)--
+                           -----(5F2)->
+                  #############(5G1)##>
+                           &lt;----(5H1)--
+                           -----(5H2)->
+                  &lt;############(5G2)###
+                  #############(5G3)##>
+                   ============(6)====>
+		                       ------(7)----->
+                                      &lt;------(8)------
+                  &lt;==========(9)======
+    &lt;-----(10)----
+   (11)----------->
+                   ==========(12)=====>
+                                       -------------->
+                                      &lt;---------------
+                   &lt;===================
+    &lt;-------------
+          </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<p>
+<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Timing of opportunistic encryption transaction&nbsp;</b></font><br></td></tr></table><hr size="1" shade="0">
+
+<blockquote class="text"><dl>
+<dt>(1)</dt>
+<dd>Human or application clicks with a name.
+</dd>
+<dt>(2)</dt>
+<dd>Application initiates DNS mapping.
+</dd>
+<dt>(3)</dt>
+<dd>Resolver returns A record to application.
+</dd>
+<dt>(4)</dt>
+<dd>Application starts a TCP session or UDP.
+</dd>
+<dt>(5)</dt>
+<dd>SG-A (host or SG) sees datagram to target, and buffers it.
+</dd>
+<dt>(5B)</dt>
+<dd>SG-A asks DNS for TXT record.
+</dd>
+<dt>(5C)</dt>
+<dd>DNS returns TXT record(s).
+</dd>
+<dt>(5D)</dt>
+<dd>Initial IKE Main Mode Packet goes out.
+</dd>
+<dt>(5E)</dt>
+<dd>IKE ISAKMP phase 1 succeeds.
+</dd>
+<dt>(5F)</dt>
+<dd>SG-B asks DNS for TXT record to prove SG-A is an agent for Alice.
+</dd>
+<dt>(5G)</dt>
+<dd>IKE phase 2 negotiation.
+</dd>
+<dt>(5H)</dt>
+<dd>DNS lookup by responder (SG-B).
+</dd>
+<dt>(6)</dt>
+<dd>Buffered datagram is sent by SG-A.
+</dd>
+<dt>(7)</dt>
+<dd>Datagram is received by SG-B, decrypted, and sent to Bob.
+</dd>
+<dt>(8)</dt>
+<dd>Bob replies, and datagram is seen by SG-B.
+</dd>
+<dt>(9)</dt>
+<dd>SG-B already has tunnel up with SG-A, and uses it.
+</dd>
+<dt>(10)</dt>
+<dd>SG-A decrypts datagram and gives it to Alice.
+</dd>
+<dt>(11)</dt>
+<dd>Alice receives datagram. Sends new packet to Bob.
+</dd>
+<dt>(12)</dt>
+<dd>SG-A gets second datagram, sees that tunnel is up, and uses it.
+</dd>
+</dl></blockquote><p>
+</p>
+<p>
+  For the purposes of this section, we will describe only the changes that
+  occur between <a href="#regulartiming">Timing of regular transaction</a> and
+  <a href="#opportunistictiming">Timing of opportunistic encryption transaction</a>. This corresponds to time points 5, 6, 7, 9 and 10 on the list above. 
+  
+</p>
+<a name="rfc.section.11.2.1"></a><h4><a name="anchor57">11.2.1</a>&nbsp;(5) IPsec datagram interception</h4>
+
+<p>
+    At point (5), SG-A intercepts the datagram because this source/destination pair lacks a policy 
+(the non-existent policy state). SG-A creates a hold policy, and buffers the datagram. SG-A requests keys from the keying daemon. 
+    
+</p>
+<a name="rfc.section.11.2.2"></a><h4><a name="anchor58">11.2.2</a>&nbsp;(5B) DNS lookup for TXT record</h4>
+
+<p>
+    SG-A's IKE daemon, having looked up the source/destination pair in the connection
+    class list, creates a new Potential OE connection instance. SG-A starts DNS
+    queries.
+    
+</p>
+<a name="rfc.section.11.2.3"></a><h4><a name="anchor59">11.2.3</a>&nbsp;(5C) DNS returns TXT record(s)</h4>
+
+<p>
+  DNS returns properly formed TXT delegation records, and SG-A's IKE daemon
+  causes this instance to make a transition from Potential OE connection to Pending OE
+  connection.
+  
+</p>
+<p>
+      Using the example above, the returned record might contain:
+
+    <br><hr size="1" shade="0">
+<a name="txtexample"></a>
+</p>
+</font><pre>
+X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
+          </pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<p>
+<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Example of reverse delegation record for Bob&nbsp;</b></font><br></td></tr></table><hr size="1" shade="0">
+
+    with SG-B's IP address and public key listed.
+    
+</p>
+<a name="rfc.section.11.2.4"></a><h4><a name="anchor60">11.2.4</a>&nbsp;(5D) Initial IKE main mode packet goes out</h4>
+
+<p>Upon entering Pending OE connection, SG-A sends the initial ISAKMP
+  message with proposals. See <a href="#phase1id">Phase 1 parameters</a>.
+  
+</p>
+<a name="rfc.section.11.2.5"></a><h4><a name="anchor61">11.2.5</a>&nbsp;(5E1) Message 2 of phase 1 exchange</h4>
+
+<p>
+  SG-B receives the message. A new connection instance is created in the
+  unauthenticated OE peer state.
+  
+</p>
+<a name="rfc.section.11.2.6"></a><h4><a name="anchor62">11.2.6</a>&nbsp;(5E2) Message 3 of phase 1 exchange</h4>
+
+<p>
+  SG-A sends a Diffie-Hellman exponent. This is an internal state of the
+  keying daemon.
+  
+</p>
+<a name="rfc.section.11.2.7"></a><h4><a name="anchor63">11.2.7</a>&nbsp;(5E3) Message 4 of phase 1 exchange</h4>
+
+<p>
+  SG-B responds with a Diffie-Hellman exponent. This is an internal state of the
+  keying protocol.
+  
+</p>
+<a name="rfc.section.11.2.8"></a><h4><a name="anchor64">11.2.8</a>&nbsp;(5E4) Message 5 of phase 1 exchange</h4>
+
+<p>
+  SG-A uses the phase 1 SA to send its identity under encryption. 
+  The choice of identity is discussed in <a href="#phase1id">Phase 1 parameters</a>.
+  This is an internal state of the keying protocol.
+  
+</p>
+<a name="rfc.section.11.2.9"></a><h4><a name="anchor65">11.2.9</a>&nbsp;(5F1) Responder lookup of initiator key</h4>
+
+<p>
+  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="#KEY">Use of KEY record</a> for further details. 
+  
+</p>
+<a name="rfc.section.11.2.10"></a><h4><a name="anchor66">11.2.10</a>&nbsp;(5F2) DNS replies with public key of initiator</h4>
+
+<p>
+Upon successfully authenticating the peer, the connection instance makes a
+transition to authenticated OE peer on SG-B.
+
+</p>
+<p>
+The format of the TXT record returned is described in
+<a href="#TXT">Use of TXT delegation record</a>. 
+
+</p>
+<a name="rfc.section.11.2.11"></a><h4><a name="anchor67">11.2.11</a>&nbsp;(5E5) Responder replies with ID and authentication</h4>
+
+<p>
+    SG-B sends its ID along with authentication material. This is an internal
+    state for the keying protocol.
+  
+</p>
+<a name="rfc.section.11.2.12"></a><h4><a name="anchor68">11.2.12</a>&nbsp;(5G) IKE phase 2</h4>
+
+<a name="rfc.section.11.2.12.1"></a><h4><a name="anchor69">11.2.12.1</a>&nbsp;(5G1) Initiator proposes tunnel</h4>
+
+<p>
+    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.
+    
+</p>
+<a name="rfc.section.11.2.12.2"></a><h4><a name="anchor70">11.2.12.2</a>&nbsp;(5H1) Responder determines initiator's authority</h4>
+
+<p>
+    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. 
+    
+</p>
+<p>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.
+</p>
+<a name="rfc.section.11.2.12.3"></a><h4><a name="anchor71">11.2.12.3</a>&nbsp;(5H2) DNS replies with TXT record(s)</h4>
+
+<p>
+      The returned key and IP address should match that of SG-A.
+    
+</p>
+<a name="rfc.section.11.2.12.4"></a><h4><a name="anchor72">11.2.12.4</a>&nbsp;(5G2) Responder agrees to proposal</h4>
+
+<p>
+    Should additional communication occur between, for instance, Dave and Bob using
+    SG-A and SG-B, a new tunnel (phase 2 SA) would be established. The phase 1 SA
+    may be reusable.
+    
+</p>
+<p>SG-A, having successfully keyed the tunnel, now makes a transition from
+    Pending OE connection to Keyed OE connection.
+    
+</p>
+<p>The responder MUST setup the inbound IPsec SAs before sending its reply.
+</p>
+<a name="rfc.section.11.2.12.5"></a><h4><a name="anchor73">11.2.12.5</a>&nbsp;(5G3) Final acknowledgment from initiator</h4>
+
+<p>
+    The initiator agrees with the responder's choice and sets up the tunnel.
+    The initiator sets up the inbound and outbound IPsec SAs.
+    
+</p>
+<p>
+    The proper authorization returned with keys prompts SG-B to make a transition
+    to the keyed OE connection state. 
+    
+</p>
+<p>Upon receipt of this message, the responder may now setup the outbound
+    IPsec SAs.
+</p>
+<a name="rfc.section.11.2.13"></a><h4><a name="anchor74">11.2.13</a>&nbsp;(6) IPsec succeeds, and sets up tunnel for communication between Alice and Bob</h4>
+
+<p>
+  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). 
+  
+</p>
+<a name="rfc.section.11.2.14"></a><h4><a name="anchor75">11.2.14</a>&nbsp;(9) SG-B already has tunnel up with G1 and uses it</h4>
+
+<p>
+  At (9), SG-B has already established an SPD entry mapping Bob->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).
+  
+</p>
+<a name="securityconsiderations"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.12"></a><h3>12.&nbsp;Security considerations</h3>
+
+<a name="rfc.section.12.1"></a><h4><a name="anchor76">12.1</a>&nbsp;Configured vs opportunistic tunnels</h4>
+
+<p>
+    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. 
+
+</p>
+<p>
+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. 
+
+</p>
+<p>
+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. 
+
+</p>
+<p>
+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.
+
+</p>
+<p>
+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. 
+
+</p>
+<p>
+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.
+
+</p>
+<p>
+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.
+
+</p>
+<a name="rfc.section.12.2"></a><h4><a name="anchor77">12.2</a>&nbsp;Firewalls versus Opportunistic Tunnels</h4>
+
+<p>
+  Typical usage of per datagram access control lists is to implement various
+kinds of security gateways. These are typically called "firewalls". 
+
+</p>
+<p>
+  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.
+
+</p>
+<p> 
+  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.
+
+</p>
+<a name="rfc.section.12.3"></a><h4><a name="anchor78">12.3</a>&nbsp;Denial of service</h4>
+
+<p>
+  There are several different forms of denial of service that an implementor 
+  should concern themselves with. Most of these problems are shared with
+  security gateways that have large numbers of mobile peers (road warriors). 
+
+</p>
+<p>
+  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. 
+
+</p>
+<a name="anchor79"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.13"></a><h3>13.&nbsp;IANA Considerations</h3>
+
+<p>
+    There are no known numbers which IANA will need to manage.
+
+</p>
+<a name="anchor80"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.14"></a><h3>14.&nbsp;Acknowledgments</h3>
+
+<p>
+        Substantive portions of this document are based upon previous work by
+        Henry Spencer.
+
+</p>
+<p>
+	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.
+
+</p>
+<p>
+	Sandra Hoffman and Bill Dickie did the detailed proof reading and editing.
+
+</p>
+<a name="rfc.references1"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<h3>Normative references</h3>
+<table width="99%" border="0">
+<tr><td class="author-text" valign="top"><b><a name="OEspec">[1]</a></b></td>
+<td class="author-text"><a href="mailto:hugh@mimosa.com">Redelmeier, D.</a> and <a href="mailto:henry@spsystems.net">H. Spencer</a>, "Opportunistic Encryption", paper http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/opportunism.spec, May 2001.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC0791">[2]</a></b></td>
+<td class="author-text">Defense Advanced Research Projects Agency (DARPA), Information Processing Techniques Office and University of Southern California (USC)/Information Sciences Institute, "<a href="ftp://ftp.isi.edu/in-notes/rfc791.txt">Internet Protocol</a>", STD 5, RFC 791, September 1981.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC1009">[3]</a></b></td>
+<td class="author-text"><a href="mailto:">Braden, R.</a> and <a href="mailto:">J. Postel</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1009.txt">Requirements for Internet gateways</a>", RFC 1009, June 1987.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC1984">[4]</a></b></td>
+<td class="author-text">IAB, IESG, <a href="mailto:brian@dxcoms.cern.ch">Carpenter, B.</a> and <a href="mailto:fred@cisco.com">F. Baker</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1984.txt">IAB and IESG Statement on Cryptographic Technology and the Internet</a>", RFC 1984, August 1996.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2119">[5]</a></b></td>
+<td class="author-text"><a href="mailto:-">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, March 1997.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2367">[6]</a></b></td>
+<td class="author-text"><a href="mailto:danmcd@eng.sun.com">McDonald, D.</a>, <a href="mailto:cmetz@inner.net">Metz, C.</a> and <a href="mailto:phan@itd.nrl.navy.mil">B. Phan</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2367.txt">PF_KEY Key Management API, Version 2</a>", RFC 2367, July 1998.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2401">[7]</a></b></td>
+<td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">Security Architecture for the Internet Protocol</a>", RFC 2401, November 1998.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2407">[8]</a></b></td>
+<td class="author-text"><a href="mailto:ddp@network-alchemy.com">Piper, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2407.txt">The Internet IP Security Domain of Interpretation for ISAKMP</a>", RFC 2407, November 1998.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2408">[9]</a></b></td>
+<td class="author-text"><a href="mailto:wdm@tycho.ncsc.mil">Maughan, D.</a>, <a href="mailto:mss@tycho.ncsc.mil">Schneider, M.</a> and <a href="er@raba.com">M. Schertler</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2408.txt">Internet Security Association and Key Management Protocol (ISAKMP)</a>", RFC 2408, November 1998.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2409">[10]</a></b></td>
+<td class="author-text"><a href="mailto:dharkins@cisco.com">Harkins, D.</a> and <a href="mailto:carrel@ipsec.org">D. Carrel</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2409.txt">The Internet Key Exchange (IKE)</a>", RFC 2409, November 1998.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC3526">[11]</a></b></td>
+<td class="author-text"><a href="mailto:kivinen@ssh.fi">Kivinen, T.</a> and <a href="mailto:mrskojo@cc.helsinki.fi">M. Kojo</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc3526.txt">More MODP Diffie-Hellman groups for IKE</a>", RFC 3526, March 2003.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC1034">[12]</a></b></td>
+<td class="author-text">Mockapetris, P., "<a href="ftp://ftp.isi.edu/in-notes/rfc1034.txt">Domain names - concepts and facilities</a>", STD 13, RFC 1034, November 1987.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC1035">[13]</a></b></td>
+<td class="author-text"><a href="mailto:">Mockapetris, P.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1035.txt">Domain names - implementation and specification</a>", STD 13, RFC 1035, November 1987.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2671">[14]</a></b></td>
+<td class="author-text"><a href="mailto:vixie@isc.org">Vixie, P.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2671.txt">Extension Mechanisms for DNS (EDNS0)</a>", RFC 2671, August 1999.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC1464">[15]</a></b></td>
+<td class="author-text"><a href="mailto:rosenbaum@lkg.dec.com">Rosenbaum, R.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1464.txt">Using the Domain Name System To Store Arbitrary String Attributes</a>", RFC 1464, May 1993.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2535">[16]</a></b></td>
+<td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2535.txt">Domain Name System Security Extensions</a>", RFC 2535, March 1999.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC3110">[17]</a></b></td>
+<td class="author-text">Eastlake, D., "<a href="ftp://ftp.isi.edu/in-notes/rfc3110.txt">RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</a>", RFC 3110, May 2001.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2538">[18]</a></b></td>
+<td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a> and <a href="mailto:ogud@tislabs.com">O. Gudmundsson</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2538.txt">Storing Certificates in the Domain Name System (DNS)</a>", RFC 2538, March 1999.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2748">[19]</a></b></td>
+<td class="author-text"><a href="mailto:David.Durham@intel.com">Durham, D.</a>, <a href="mailto:jboyle@Level3.net">Boyle, J.</a>, <a href="mailto:ronc@cisco.com">Cohen, R.</a>, <a href="mailto:herzog@iphighway.com">Herzog, S.</a>, <a href="mailto:rajan@research.att.com">Rajan, R.</a> and <a href="mailto:asastry@cisco.com">A. Sastry</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2748.txt">The COPS (Common Open Policy Service) Protocol</a>", RFC 2748, January 2000.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2663">[20]</a></b></td>
+<td class="author-text"><a href="mailto:srisuresh@lucent.com">Srisuresh, P.</a> and <a href="mailto:holdrege@lucent.com">M. Holdrege</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2663.txt">IP Network Address Translator (NAT) Terminology and Considerations</a>", RFC 2663, August 1999.</td></tr>
+</table>
+
+<a name="rfc.authors"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<h3>Authors' Addresses</h3>
+<table width="99%" border="0" cellpadding="0" cellspacing="0">
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">Michael C. Richardson</td></tr>
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">Sandelman Software Works</td></tr>
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">470 Dawson Avenue</td></tr>
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">Ottawa, ON  K1Z 5V7</td></tr>
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">CA</td></tr>
+<tr><td class="author" align="right">EMail:&nbsp;</td>
+<td class="author-text"><a href="mailto:mcr@sandelman.ottawa.on.ca">mcr@sandelman.ottawa.on.ca</a></td></tr>
+<tr><td class="author" align="right">URI:&nbsp;</td>
+<td class="author-text"><a href="http://www.sandelman.ottawa.on.ca/">http://www.sandelman.ottawa.on.ca/</a></td></tr>
+<tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">D. Hugh Redelmeier</td></tr>
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">Mimosa</td></tr>
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">Toronto, ON</td></tr>
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">CA</td></tr>
+<tr><td class="author" align="right">EMail:&nbsp;</td>
+<td class="author-text"><a href="mailto:hugh@mimosa.com">hugh@mimosa.com</a></td></tr>
+</table>
+<a name="rfc.copyright"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<h3>Full Copyright Statement</h3>
+<p class='copyright'>
+Copyright (C) The Internet Society (2003). All Rights Reserved.</p>
+<p class='copyright'>
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it
+or assist in its implementation may be prepared, copied, published and
+distributed, in whole or in part, without restriction of any kind,
+provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by removing
+the copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of
+developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be
+followed, or as required to translate it into languages other than
+English.</p>
+<p class='copyright'>
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.</p>
+<p class='copyright'>
+This document and the information contained herein is provided on an
+&quot;AS IS&quot; basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS 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.</p>
+<h3>Acknowledgement</h3>
+<p class='copyright'>
+Funding for the RFC Editor function is currently provided by the
+Internet Society.</p>
+</font></body></html>
diff --git a/doc/src/draft-richardson-ipsec-opportunistic.xml b/doc/src/draft-richardson-ipsec-opportunistic.xml
new file mode 100644
index 000000000..d587df693
--- /dev/null
+++ b/doc/src/draft-richardson-ipsec-opportunistic.xml
@@ -0,0 +1,2519 @@
+<?xml version="1.0"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
+<?rfc toc="yes"?>
+<?rfc tocdepth='2' ?>
+
+<rfc ipr="full2026" docName="draft-richardson-ipsec-opportunistic-12.txt">
+
+<front>
+  <area>Security</area>
+  <workgroup>Independent submission</workgroup>
+  <title abbrev="opportunistic">
+     Opportunistic Encryption using The Internet Key Exchange (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>
+
+  <date month="June" year="2003"></date>
+
+<abstract>
+  <t>
+This document describes opportunistic encryption (OE) using the Internet Key
+Exchange (IKE) and IPsec.  
+Each system administrator adds new
+resource records to his or her Domain Name System (DNS) to support
+opportunistic encryption. The objective is to allow encryption for secure communication without
+any pre-arrangement specific to the pair of systems involved.
+  </t>
+  <t>
+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. 
+  </t>
+  <t>
+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.
+  </t>
+  <t>
+This document is offered up as an Informational RFC.
+  </t>
+</abstract>
+
+</front>
+
+<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 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.
+</t>
+
+<t>
+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 RFC3445, in a backward compatible way.
+For project information, see http://www.freeswan.org.
+</t>
+
+  <t>
+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 <xref target="RFC1984" />.
+The Linux FreeS/WAN project attempts to provide a practical means to implement this policy. 
+  </t>
+
+  <t>
+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. 
+  </t>
+
+  <t>
+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.
+  </t>
+
+  <t>
+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 - as 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.
+</t>
+
+  <t>
+This document describes the infrastructure to permit deployment of
+Opportunistic Encryption.
+</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 understanding 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 permitted.</t>
+      <t hangText="* Opportunistic tunnel:"> networks to which traffic is encrypted if possible, but otherwise is in the clear  
+	    or fails depending on the default policy in place.	
+      </t>
+      <t hangText="* Configured tunnel:"> networks to which traffic
+must be encrypted, and traffic in the clear is never permitted.
+A Virtual Private Network (VPN) is a form of configured tunnel.
+</t>
+    </list>      
+  </t>
+
+<t>
+Traditional firewall devices handle the first two categories.
+No authentication is required.  
+The permit policy is currently the default on the Internet. 
+</t>
+
+<t>
+This document describes the third category - opportunistic tunnel, which is
+proposed as the new default for 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 a single authority, arranging for distribution of
+  authentication material, while difficult, does not require any new
+  technology. The mechanism described here provides an additional way to
+  distribute the authentication materials, that of a public key method that does not
+  require deployment of an X.509 based infrastructure.  
+</t>
+<t>
+Current Virtual Private Networks can often be replaced by an "OE paranoid"
+policy as described herein. 
+</t>
+</section>	
+
+<section title="Peer authentication in opportunistic encryption">
+
+  <t>
+  Opportunistic encryption creates tunnels between nodes that
+  are essentially strangers. This is done without any prior bilateral
+  arrangement. 
+  There is, therefore, the difficult question of how one knows to whom one is
+  talking.
+  </t>
+
+  <t>
+  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.
+  </t>
+
+  <t>
+Although 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 desireable goal.
+The latter is achieved through key distribution in DNS, leveraging upon
+the authentication of the DNS in DNSSEC.
+</t>
+
+  <t>
+  Peers are, therefore, authenticated with DNSSEC when available. Local policy 
+determines how much trust to extend when DNSSEC is not available.
+  </t>
+
+  <t>
+  However, 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.
+  </t>
+  
+  <t>
+  When initiating outbound opportunistic encryption, local 
+  configuration determines what happens if tunnel setup fails. It may be that
+  the packet goes out in the clear, or it may be dropped.
+  </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 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/B is an independent organization, AS2.
+    Nodes Q and R are nodes 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 (or simply gateway):"> a system that performs IPsec tunnel
+    mode encapsulation/decapsulation. [SG-x] 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 period represents an untrusted network of unknown
+        type.</t> 
+    <t hangText="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.</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 cannot know the
+		  current address for the road warrior. </t>
+
+    <t hangText="Anonymous encryption:">
+	the process of encrypting a session without any knowledge of who the
+	other parties are. No authentication of identities is done.</t>
+
+    <t hangText="Opportunistic encryption:">
+	the process of encrypting a session with authenticated knowledge of
+	who the other party is.</t>
+
+    <t hangText="Lifetime:">
+        the period in seconds (bytes or datagrams) for which a security
+	association will remain alive before needing to be re-keyed.</t>
+
+    <t hangText="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.</t>
+    
+    <t hangText="Phase 1 SA:"> an ISAKMP/IKE security association sometimes
+      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="AS:"> an autonomous system </t>
+
+    <t hangText="FQDN:"> Fully-Qualified Domain Name </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 the 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 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 end point which should be used. 
+</t>
+
+<section title="Tunnel authorization">
+<t>
+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 <xref target="TXT"/>). 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.
+</t>
+</section> 
+
+<section title="Tunnel end-point discovery">
+
+<t>
+The authorization resource record also provides the address or name of the tunnel
+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 the public RSA key is not 
+present, the OE gateway performs a second lookup to find a KEY 
+resource record for the end point address or name.
+</t>
+<t>
+Origin and integrity protection of the resource records is provided by 
+DNSSEC (<xref target="RFC2535"/>). <xref target="nodnssec"/>
+documents an optional 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 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. 
+</t>
+
+<t>
+Successful negotiation of OE instantiates a new security association. 
+Failure to negotiate OE results in creation of a 
+forwarding policy entry either to drop or transmit in the clear future
+datagrams. This negative cache is necessary to avoid the possibly lengthy process of repeatedly looking 
+up the same information.
+</t>
+
+<t>
+The cache is timed out periodically, as described in <xref target="teardown" />.
+This removes entries that are no longer
+being used and permits the discovery of changes in authorization policy.
+</t>
+</section>
+
+</section> <!-- "Model of operation" -->
+
+</section> <!-- "Overview" -->
+
+<section title="Protocol Specification">
+
+<t>
+The OE gateway is modeled to have a forwarding plane and a control
+plane. A control channel, such as PF_KEY, connects the two planes. 
+(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, peer authentication and key derivation functions.   
+</t>
+
+<section title="Forwarding plane state machine">
+
+<t>
+Let the OE gateway maintain a collection of objects -- a superset of the
+security policy database (SPD) specified in <xref target="RFC2401" />. 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.
+</t>
+
+<!-- from file forwardingstate.txt -->
+<artwork><![CDATA[
+      .--------------. 	 
+      | non-existant |
+      |    policy    |
+      `--------------'
+             |        
+             | PF_ACQUIRE
+             |           
+             |<---------.
+             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 |--'        
+                           '-------------'          
+]]></artwork>
+
+
+<section title="Non-existent policy">
+<t>
+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. 
+
+</t>
+</section>
+
+<section title="Hold policy">
+<t>
+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 transmission.
+If there is a datagram already so stored, then that already stored datagram is discarded.
+</t>
+<t>
+The rational behind saving the 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 to 
+for the end-point to retransmit the datagram. In the case where the connection
+was not a TCP connection, buyt 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 end-points determine
+which data awas dropped while negotiation took place.  
+</t>
+</section>
+
+<section title="Pass-through policy">
+<t>
+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.
+</t>
+</section>
+
+<section title="Deny policy">
+<t>
+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 administator 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). 
+</t>
+</section>
+
+<section title="Encrypt policy">
+<t>
+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.  
+</t>
+<t>
+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.
+</t>
+</section>
+
+<t>
+All states may be created directly by the keying daemon while acting as a
+gateway. 
+</t>
+
+</section> <!-- "Datagram state machine" -->
+
+
+<section anchor="initclasses" title="Keying Daemon -- initiator">
+<t>
+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 - what could be. An instance represents an actual connection -  
+what is implemented at the time.
+</t>
+
+<t>
+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.
+</t>
+
+<t>
+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 source and/or destination
+addresses 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.
+</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 machine's state transitions, the states
+associated with the keying system itself are omitted because 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 that implementations inter-operate.
+</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
+set 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 description of the state machine.
+</t>
+
+<!-- from file initiatorstate.txt -->
+<artwork><![CDATA[
+
+                       |
+	               | PF_ACQUIRE
+		       |     
+                       V
+                .---------------.       
+                |  non-existant |
+                |  connection   |
+                `---------------'
+                 |      |      |
+          send   ,      |      \
+expired   pass  /       |       \ send
+conn.     msg  /        |        \ deny
+  ^           /         |         \ msg
+  |          V          | do       \ 		 
+.---------------.       | DNS       \   .---------------.  
+|  clear-text   |	| lookup     `->|     deny      |---> 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 |---------'
+   |              | & parse TXT RR|         ^
+   | repeated     `---------------'         |
+   | ICMP               |                   |
+   | failures           | initiate IKE to   |                         
+   | (short-timeout)    | responder         |                         
+   |                    V                   |                          
+   | phase-2      .---------------.         | failure                       
+   | failure      |   pending     |---------'                          
+   | (normal      |     OE        |         ^                          
+   |  timeout)    |               |invalid  | phase-2 failure (short-timeout)
+   |              |               |<--.SPI  | ICMP failures (normal timeout)
+   |              |               |   |     |                          
+   |              | +=======+     |---'     |                          
+   |              | |  IKE  |     |   ^     |                          
+   `--------------| | states|---------------'                          
+                  | +=======+     |   |                                
+                  `---------------'   |                                
+                        | IPsec SA    | invalid SPI                    
+                        | established |                                
+	                V             | rekey time                     
+                  .--------------.    |                                
+                  |   keyed      |<---|-------------------------------.
+                  |  connection  |----'                               |
+                  `--------------'                                    |
+                        | timer                                       |
+                        |                                             |
+                        V                                             |
+                  .--------------.     connection still active        |
+  clear-text----->|   expired    |------------------------------------'
+        deny----->|  connection  |
+                  `--------------'
+                        | dead connected - deleted
+                        V
+]]></artwork>
+
+
+<section title="Nonexistent connection">
+<t>
+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.
+</t>
+<t>Failure to find an appropriate connection class results in an
+administrator defined default. 
+</t>
+<t>
+In each case, when the initiator finds an appropriate class for the new flow, 
+an instance connection is made of the class which matched.
+</t>
+</section>
+
+<section title="Clear-text connection">
+<t>
+The non-existent 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.
+</t>
+<t>
+Timing out is the only way to leave this state
+(see <xref target="expiring" />).
+</t>
+</section>
+
+<section title="Deny connection">
+<t>
+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.  
+</t>
+<t>
+Timing out is the only way to leave this state 
+(see <xref target="expiring" />).
+</t>
+</section>
+
+<section title="Potential OE connection">
+<t>
+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.  
+</t>
+<t>
+In addition, when making a transition into this state, DNS lookup is done in
+the reverse-map for a TXT delegation resource record (see <xref target="TXT" />).
+The lookup key is the destination address of the flow.
+</t>
+<t>
+There are three ways to exit this state: 
+<list style="numbers">
+<t>DNS lookup finds a TXT delegation resource record.</t>
+<t>DNS lookup does not find a TXT delegation resource record.</t>
+<t>DNS lookup times out.</t>
+</list>
+</t>
+
+<t>
+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:
+<list style="numbers">
+<t>DNS finds an appropriate resource record</t>
+<t>It is properly formatted according to <xref target="TXT" /></t>
+<t> if DNSSEC is enabled, then the signature has been vouched for.</t>
+</list>
+
+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.
+</t>
+<t>
+If DNS lookup does not find a resource record or 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.
+</t>
+<t>
+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.
+</t>
+
+<section anchor="nodnssec" title="Restriction on unauthenticated 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>
+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.  
+</t>
+<t>
+Exit from this state occurs 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>
+Three failures have caused significant problems. They are clearly not the
+only possible failures from keying.
+</t>
+<t>
+Note that if there are 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 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. 
+</t>
+<t>
+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.
+</t>
+<t>
+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. 
+</t>
+<t>
+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 than non-signed records.) 
+<!-- dig @gateway would also work here -->
+</t>
+
+</section>
+
+<section anchor="keyed" title="Keyed connection">
+<t>
+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.
+</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 the expired connection state.
+</t>
+<t>
+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 to use 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.
+</t>
+<t>
+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. 
+</t>
+</section>
+
+<section anchor="expiring" title="Expiring connection">
+<t>
+The initiator will periodically place each of the deny, clear-text, and keyed
+connections into this  
+sub-state. See <xref target="teardown" /> 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. 
+</t>
+<t>
+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 <xref target="RFC1034" /> section 4.3.4.)
+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.
+</t>
+<t> 
+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.
+</t>
+<t>
+Also 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">
+<t>
+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. 
+</t>
+<t>
+The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs as described in
+<xref target="teardown" />. 
+</t>
+<t>
+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.
+</t>
+</section>
+
+</section> <!-- "Keying state machine - initiator" -->
+
+<section title="Keying Daemon - responder">
+<t>
+The responder has a set of objects identical to those of the initiator.
+</t>
+<t>
+The responder receives an invitation to create a keying channel from an initiator. 
+</t>
+
+<!-- from file responderstate.txt -->
+<artwork><![CDATA[
+                |
+                | 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  |---------------> log failure
+        |     reply       | 
+        `----+--------+---'
+     phase 2 |        \      misformatted 
+    proposal |         `------------------> log failure
+             V
+    .----------------.
+    |  authenticated |  identical initiator 
+    |     OE peer    |--------------------> initiator 
+    `----------------'  connection found    state machine
+         |
+         | look for TXT record for initiator
+	 |
+         V  
+   .---------------.
+   |  authorized   |---------------------> log failure
+   |    OE peer    |
+   `---------------'
+         |
+         |
+         V
+    potential OE
+    connection in
+    initiator state
+	machine
+
+
+$Id: draft-richardson-ipsec-opportunistic.xml,v 1.1 2004/03/15 20:35:24 as Exp $
+]]></artwork>
+
+
+<section title="Unauthenticated OE peer">
+<t>
+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 <xref target="RFC2407" /> section 
+4.6.2.1.)
+</t>
+<t>
+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.
+</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 the
+authenticated OE Peer state.
+</t>
+<t>
+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.
+</t>
+</section>
+
+<section title="Authenticated OE Peer">
+<t>
+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. 
+</t>
+<t> 
+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.
+</t>
+<t> 
+If an identical connection is not found, then the responder makes the 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 tunnels are no longer in use is the subject of this section.
+</t>
+
+<t>
+There are two methods for removing tunnels: explicit deletion or expiry. 
+</t>
+
+<t>
+Explicit deletion requires an IKE delete message. As the deletes
+MUST be authenticated, both ends of the tunnel must maintain the 
+key channel (phase 1 ISAKMP SA). An implementation which refuses to either maintain or
+recreate the keying channel SA will be unable to use this method.
+</t>
+
+<t>
+The tunnel expiry method simply allows the IKE daemon to
+expire normally without attempting to re-key it.
+</t>
+
+<t>
+Regardless of which method is used to remove tunnels, the implementation MUST
+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.
+</t>
+
+<t>
+Set a short initial (soft) lifespan of 1 minute since many net flows last
+only a few seconds.
+</t>
+
+<t>
+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.
+</t>
+
+<t>
+The expiring state in the key management
+system (see <xref target="expiring" />) implements these timeouts.
+The timer above may be in the forwarding plane, 
+but then it must be re-settable. 
+</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.) 
+Unlike re-keying, this tunnel use check is not costly and should happen
+reasonably frequently.
+</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 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.
+</t>
+
+</section> <!-- "Aging" -->
+
+<section title="Teardown and cleanup">
+
+<t>
+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.
+</t>
+
+<t>
+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 which 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. 
+</t>
+<t>
+Tunnels are to be considered as bidirectional entities, even though the
+low-level protocols don't treat them this 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 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.)
+</t>
+
+<t>
+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 outgoing SAs) 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 for nonces,
+    cookies and so on. 
+    </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 co-resident on the same gateway.
+    </t>
+  </section>
+
+  <section title="Gateway discovery process">
+  <t>
+  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.
+  </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 implemented for proof of concept, experience
+is that it can cause very high latencies when a queue of queries must
+all timeout in series. 
+  </t>
+  <t> 
+  Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with
+  some of the protocol steps.
+  </t>
+  </section>
+
+  <section title="Self identification">
+  <t>
+     SG-A will have to establish its identity. Use 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) 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 <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 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.
+  </t>
+  <t> 
+     It is reasonable that if other non-local sources of policy are used
+     (COPS, LDAP), they be consulted concurrently but 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.
+  </t>
+  </section>
+  
+  <section title="Interactions with DNSSEC">
+  <t>
+     The implementation described (1.98) neither uses DNSSEC directly to
+     explicitly verify the authenticity of zone information, nor uses the NXT
+     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. 
+  </t>
+  <t> 
+     To distinguish between an authenticated and an unauthenticated DNS
+     resource record, a stub resolver capable of returning DNSSEC
+     information MUST be used.
+  </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="Required 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="RFC3526" />
+      </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>
+        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 <xref
+        target="fqdn" />.) 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).
+      </t>
+    </section>
+
+    <section anchor="phase2id" title="Phase 2 parameters">
+      <t>
+        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.
+      </t>
+      <t>
+        Tunnel mode MUST be used.
+      </t>
+      <t>
+        Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32.
+      </t>
+      <t>
+        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.
+      </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 identities, security gateways SHOULD publish
+    their public keys in their reverse DNS 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 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.</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>
+  <t>Use of several KEY records allows for key rollover. The SIG Payload in
+  IKE phase 1 SHOULD be accepted if the public key given by any KEY RR
+  validates it.
+  </t>
+  </section>
+
+  <section anchor="TXT" title="Use of TXT delegation record">
+    <t>
+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. Similarly for Bob and SG-B.
+</t>
+
+<t>
+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.
+    </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
+    uses the following syntax, as suggested in <xref target="RFC1464">RFC1464</xref>.
+    (Note that the reply to query may include other TXT resource
+    records used by other applications.)
+
+    <figure anchor="txtformat" title="Format of reverse delegation record">
+           <artwork><![CDATA[
+X-IPsec-Server(P)=A.B.C.D KEY
+          ]]></artwork>
+    </figure>
+    </t>
+
+    where the record is formed by the following fields:
+
+    <list style="hanging"> 
+      <t hangText="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. The 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.
+      </t> 
+    </list>
+
+    <t>
+  	The fields of the record MUST be separated by whitespace. This
+        MAY be: space, tab, newline, or carriage return. A space is preferred.
+    </t>
+
+    <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. 
+      </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="Long TXT records">
+  <t>
+  When packed into transport format, TXT records which are longer than 255
+  characters are divided into smaller &lt;character-strings&gt;.
+  (See <xref target="RFC1035" /> section 3.3 and 3.3.14.) These MUST
+  be reassembled into a single string for processing.
+  Whitespace characters in the base64 encoding are to be ignored.
+  </t>
+  </section>
+
+  <section title="Choice of TXT record">
+  <t>
+	It has been suggested to use the KEY, OPT, CERT, or KX records
+	instead of a TXT record. None is satisfactory.
+  </t>
+  <t> The KEY RR has a protocol field which could be used to indicate a new protocol, 
+and an algorithm field which 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.
+  </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 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.
+  </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 be proposed in a future revision of this document.
+  </t>
+  <t>
+    KX records are ideally suited for use instead of TXT records, but had not been deployed at
+    the time of implementation.
+<!-- Jakob Schlyter <j@crt.se> confirmed -->
+  </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.  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.
+    </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. </t>
+    <t>However, Alice must still delegate to  herself if she wishes others to
+       initiate OE to her.  See <xref target="txtfqdnformat" />.
+    </t>
+    <
+  </section> 
+
+<section title="Key roll-over">
+<t>
+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 it propagating 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 in additional TXT
+delegation records) at key generation time. Note: only one key is allowed in
+each TXT record.
+</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 (possesses the private key) that
+determines which key is to be used.
+</t>
+
+  </section>
+</section>
+
+
+<section title="Network address translation interaction">
+  <t>
+     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.
+  </t>
+  <t>
+     There are several situations to consider for NAT.
+  </t>
+  <section title="Co-located NAT/NAPT">
+    <t>
+       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. 
+    </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.
+        Placing of TXT records is possible.
+    </t>
+    <t> 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. 
+
+	FQDN style can be used to get around a lack of a reverse-map for
+	initiators only.
+    </t>
+  </section>
+
+  <section title="Security Gateway behind NAT/NAPT">
+    <t>
+       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.
+    </t>
+  </section>
+
+  <section title="End System is behind a NAT/NAPT">
+    <t>
+       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 initiate to the end system. It may be possible for this end
+       system to initiate in such communication. This creates an asymmetry, but this is common for 
+       NAPT.
+    </t>
+  </section>
+</section>
+
+<section title="Host implementations">
+<t>
+  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.
+</t>
+<t>
+  Components marked Alice are the upper layers (TCP, UDP, the
+  application), and SG-A is the IP layer.
+</t>
+<t>
+  Note that tunnel mode is still required. 
+</t>
+<t>
+  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.
+</t>
+</section>
+
+<section title="Multi-homing">
+<t> 
+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. 
+</t>
+<t>
+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, because Alice has published two equally weighted TXT delegation records:
+    <figure anchor="txtmultiexample"
+    title="Multiple gateway delegation example for Alice">
+           <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 do any kind of load sharing needed. Both SG-A and SG-D send datagrams addressed to Bob through
+their tunnel to SG-B. 
+</t>
+<t>
+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. 
+</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>
+SG-B may make a number of choices:
+<list style="numbers">
+<t>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.</t>
+
+<t>It can send to the gateway from which it most recently received datagrams. 
+      This assumes that routing and reachability are symmetrical.</t>
+
+<t>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. </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, accept datagrams from either SG-A or SG-D, but
+send only to the gateway that most recently re-keyed with it.</t> 
+</list>
+</t>
+
+<t>
+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. 
+</t>
+
+<t>
+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.
+</t>
+	
+</section>
+
+<section title="Failure modes">
+  <section title="DNS failures">
+  <t>
+  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 <xref target="initclasses" />.
+  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.
+  </t>
+  <t>
+  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.
+  </t>
+  </section>
+
+  <section title="DNS configured, IKE failures">
+  <t>
+  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.  
+  </t>
+  <t>
+  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.
+  </t>
+  <t>
+  In these situations a clear log should be produced
+  and local policy should dictate if communication is then
+  permitted in the clear.
+  </t>
+  </section>
+
+  <section title="System reboots">
+<t>
+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.
+</t>
+
+<t>
+A mechanism for recovery after reboot is a topic of current research and is not specified in this
+document.
+</t>
+
+<t>
+A deliberate shutdown should include an attempt, using deletes, 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.
+</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 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.
+  </t>
+  </section>
+</section>
+
+<section title="Examples">
+
+<section title="Clear-text usage (permit policy)">
+
+<t>
+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.
+
+<t>
+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: 
+</t>
+
+       <figure anchor="regulartiming" title="Timing of regular transaction">
+           <artwork><![CDATA[
+  Alice         SG-A       DNS       SG-B           Bob
+   Human or application
+   'clicks' with a name.
+   (1)
+
+    ------(2)-------------->
+    Application looks up
+    name in DNS to get
+    IP address.
+
+    <-----(3)---------------
+    Resolver returns "A" RR
+    to application with IP 
+    address.
+
+   (4)
+   Application starts a TCP session
+   or UDP session and OS sends
+   first datagram
+
+       ----(5)----->
+       Datagram is seen at first gateway
+       from Alice (SG-A). 
+
+                   ----------(6)------>
+                   Datagram traverses
+                   network.
+
+                                       ------(7)----->
+                                       Datagram arrives
+                                       at Bob, is provided
+                                       to TCP.
+
+                                      <------(8)------
+                                       A reply is sent.
+
+                   <----------(9)------
+                   Datagram traverses
+                   network.
+    <----(10)-----
+    Alice receives
+    answer.
+
+   (11)----------->
+    A second exchange
+    occurs.
+                   ----------(12)----->
+                                       -------------->
+                                      <---------------
+                   <-------------------
+    <-------------
+          ]]></artwork>
+</figure>
+
+</t>
+</section>
+
+<section title="Opportunistic encryption">
+
+<t>
+In the presence of properly configured opportunistic encryptors, the
+event list is extended. Only changes are annotated.
+</t>
+
+<t>The following symbols are used in the time-sequence diagram</t>
+
+<t>
+<list style="hanging">
+    <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 single tilde represents clear-text phase 1 datagrams.</t>
+    <t hangText="#"> A hash sign represents phase 1 (IKE) cipher-text
+        datagrams.</t> 
+</list>
+</t>
+
+<t>
+<figure anchor="opportunistictiming" title="Timing of opportunistic encryption transaction">
+           <artwork><![CDATA[
+  Alice          SG-A      DNS       SG-B           Bob
+   (1)
+    ------(2)-------------->
+    <-----(3)---------------
+   (4)----(5)----->+
+      SG-A sees datagram 
+      to new target and
+      saves it as "first"
+
+                  ----(5B)->
+                  SG-A asks DNS 
+                  for TXT RR.
+
+                  <---(5C)--
+                  DNS returns TXT RR.
+
+                  ~~~~~~~~~~~~~(5D)~~~>
+                  initial IKE main mode 
+                  packet is sent.       
+
+                  <~~~~~~~~~~~~(5E1)~~~
+                  ~~~~~~~~~~~~~(5E2)~~>
+                  <~~~~~~~~~~~~(5E3)~~~
+                  IKE phase 1 - privacy.
+
+                  #############(5E4)##>
+                  SG-A sends ID to SG-B
+                           <----(5F1)--
+                            SG-B asks DNS
+                            for SG-A's public 
+                            KEY
+                           -----(5F2)->
+                            DNS provides KEY RR.
+                            SG-B authenticates SG-A
+
+                  <############(5E5)###
+                  IKE phase 1 - complete
+                           
+                  #############(5G1)##>
+                  IKE phase 2 - Alice<->Bob
+                  tunnel is proposed.
+
+                           <----(5H1)--
+                            SG-B asks DNS for
+                            Alice's TXT record.
+                           -----(5H2)->
+                            DNS replies with TXT
+                            record. SG-B checks
+                            SG-A's authorization.
+
+                  <############(5G2)###
+                   SG-B accepts proposal.
+
+                  #############(5G3)##>
+                   SG-A confirms.
+
+                   ============(6)====>
+                    SG-A sends "first"
+                    packet in new IPsec
+                    SA.
+                                       ------(7)----->
+                                        packet is decrypted
+                                        and forward to Bob.
+                                      <------(8)------
+                  <==========(9)======
+                    return packet also
+                    encrypted.
+    <-----(10)----
+
+   (11)----------->
+     a second packet
+     is sent by Alice
+                   ==========(12)=====>
+                    existing tunnel is used
+                                       -------------->
+                                      <---------------
+                   <===================
+    <-------------
+          ]]></artwork>
+</figure>
+
+</t>
+
+  <t>
+  For the purposes of this section, we will describe only the changes that
+  occur between <xref target="regulartiming" /> and
+  <xref target="opportunistictiming" />. This corresponds to time points 5, 6, 7, 9 and 10 on the list above. 
+  </t>
+
+<list style="symbols">
+  <t>
+    At point (5), SG-A intercepts the datagram because this source/destination pair lacks a policy 
+(the non-existent policy state). SG-A creates a hold policy, and buffers the datagram. SG-A requests keys from the keying daemon. 
+    </t>
+
+    <t>
+    SG-A's IKE daemon, having looked up the source/destination pair in the connection
+    class list, creates a new Potential OE connection instance. SG-A starts DNS
+    queries.
+    </t>
+  </section>
+
+  <section title="(5C) DNS returns TXT record(s)">
+
+  <t>
+  DNS returns properly formed TXT delegation records, and SG-A's IKE daemon
+  causes this instance to make a transition from Potential OE connection to Pending OE
+  connection.
+  </t>
+
+    <t>
+      Using the example above, the returned record might contain:
+
+    <figure anchor="txtexample"
+    title="Example of reverse delegation record for Bob">
+           <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>
+  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 <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 makes a
+transition to authenticated OE peer on SG-B.
+</t>
+<t>
+The format of the TXT record 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 only for 
+    the Alice/Bob 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 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. 
+    </t>
+    <t>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.</t>
+    </section>
+  
+    <section title="(5H2) DNS replies with TXT record(s)">
+    <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, Dave and Bob using
+    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 makes a transition from
+    Pending OE connection to Keyed OE connection.
+    </t>
+    <t>The responder MUST setup the inbound IPsec SAs before sending its reply.</t>
+    </section>
+
+    <section title="(5G3) Final acknowledgment from initiator">
+    <t>
+    The initiator agrees with the responder's choice and sets up the tunnel.
+    The initiator sets up the inbound and outbound IPsec SAs.
+    </t>
+    <t>
+    The proper authorization returned with keys prompts SG-B to make a transition
+    to the keyed OE connection state. 
+    </t>
+    <t>Upon receipt of this message, the responder may now setup the outbound
+    IPsec SAs.</t> 
+    </section>
+  </section>
+
+  <section title="(6) IPsec succeeds, and sets up tunnel for communication between Alice and Bob">
+  <t>
+  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). 
+  </t>
+  </section>
+
+  <section title="(9) SG-B already has tunnel up with G1 and 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 datagram 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 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. 
+</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 datagrams 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 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.
+</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, opportunistic encryption can protect against passive
+eavesdropping but not against active man-in-the-middle attacks.
+</t>
+  </section>
+
+  <section title="Firewalls versus Opportunistic Tunnels">
+<t>
+  Typical usage of per datagram access control lists is to implement various
+kinds of security gateways. These are typically called "firewalls". 
+</t>
+<t>
+  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.
+</t>
+<t> 
+  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.
+</t>
+  </section>
+
+  <section title="Denial of service">
+<t>
+  There are several different forms of denial of service that 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. 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. 
+</t>
+
+</section>
+</section>
+
+<section title="IANA Considerations">
+<t>
+    There are no known numbers which IANA will need to manage.
+</t>
+</section>
+
+<section title="Acknowledgments">
+<t>
+        Substantive portions of this document are based upon previous work by
+        Henry Spencer.
+</t>
+<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>
+<t>
+	Sandra Hoffman and Bill Dickie did the detailed proof reading and editing.
+</t>
+</section>
+
+</middle>
+
+<back>
+<references title="Normative references">
+<?rfc include="reference.OEspec" ?>
+<!-- renumber according to reference order -->
+<?rfc include="reference.RFC.0791" ?>
+<?rfc include="reference.RFC.1009" ?>
+<?rfc include="reference.RFC.1984" ?>
+<?rfc include="reference.RFC.2119" ?>
+<!-- IPsec -->
+<?rfc include="reference.RFC.2367" ?>
+<?rfc include="reference.RFC.2401" ?>
+<?rfc include="reference.RFC.2407" ?>
+<?rfc include="reference.RFC.2408" ?>
+<?rfc include="reference.RFC.2409" ?>
+<!-- MODPGROUPS -->
+<?rfc include="reference.RFC.3526" ?>
+<!-- DNSSEC -->
+<?rfc include="reference.RFC.1034" ?>
+<?rfc include="reference.RFC.1035" ?>
+<?rfc include="reference.RFC.2671" ?>
+<?rfc include="reference.RFC.1464" ?>
+<?rfc include="reference.RFC.2535" ?>
+<?rfc include="reference.RFC.3110" ?>
+<?rfc include="reference.RFC.2538" ?>
+<!-- COPS -->
+<?rfc include="reference.RFC.2748" ?>
+<!-- NAT -->
+<?rfc include="reference.RFC.2663" ?>
+</references>
+<!-- <references title="Non-normative references"> -->
+<!-- ESPUDP -->
+<!-- <?rfc include="reference.ESPUDP" ?> -->
+<!-- </references> -->
+</back>
+</rfc>
+<!--
+  $Id: draft-richardson-ipsec-opportunistic.xml,v 1.1 2004/03/15 20:35:24 as Exp $
+
+  $Log: draft-richardson-ipsec-opportunistic.xml,v $
+  Revision 1.1  2004/03/15 20:35:24  as
+  added files from freeswan-2.04-x509-1.5.3
+
+  Revision 1.33  2003/06/30 03:19:59  mcr
+  	timing-diagram with inline explanation.
+
+  Revision 1.32  2003/06/30 01:57:44  mcr
+  	initial edits per-Bob Braden.
+
+  Revision 1.31  2003/05/26 19:31:23  mcr
+  	updates to drafts - IPSEC RR - SC versions, and RFC3526
+  	reference in OE draft.
+
+  Revision 1.30  2003/05/21 15:42:34  mcr
+  	updates due to publication of RFC 3526.
+
+  Revision 1.29  2003/01/17 16:22:55  mcr
+  	rev 11 of OE draft.
+
+  Revision 1.28  2002/07/25 19:27:31  mcr
+  	added DHR's minor edits.
+
+  Revision 1.27  2002/07/21 16:26:26  mcr
+  	slides from presentation at OLS
+  	draft-10 of OE draft.
+
+  Revision 1.26  2002/07/16 03:46:53  mcr
+  	second edits from Sandra.
+
+  Revision 1.25  2002/07/16 03:36:14  mcr
+  	removed HS from authors list
+  	updated reference inclusion to use <?rfc-include directive.
+  Revision 1.24  2002/07/11 02:08:21  mcr
+  	updated XML file from Sandra
+
+  Revision 1.23  2002/06/06 17:18:53  mcr
+  	spellcheck.
+
+  Revision 1.22  2002/06/06 17:14:19  mcr
+  	results of hand-editing session from May 28th.
+  	This is FINAL OE draft.
+
+  Revision 1.21  2002/06/06 02:25:44  mcr
+  	results of hand-editing session from May 28th.
+  	This is FINAL OE draft.
+
+  Revision 1.20  2002/05/24 03:28:37  mcr
+  	changes as requested by RFC editor.
+
+  Revision 1.19  2002/04/09 16:01:05  mcr
+  	comments from PHB.
+
+  Revision 1.18  2002/04/08 02:14:34  mcr
+  	RGBs changes to rev6.
+
+  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.
+
+
+!>
diff --git a/doc/src/draft-richardson-ipsec-rr.html b/doc/src/draft-richardson-ipsec-rr.html
new file mode 100644
index 000000000..08473104f
--- /dev/null
+++ b/doc/src/draft-richardson-ipsec-rr.html
@@ -0,0 +1,659 @@
+<html><head><title>A method for storing IPsec keying material in DNS.</title>
+<STYLE type='text/css'>
+    .title { color: #990000; font-size: 22px; line-height: 22px; font-weight: bold; text-align: right;
+             font-family: helvetica, arial, sans-serif }
+    .filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right;
+                  font-family: helvetica, arial, sans-serif }
+    p.copyright { color: #000000; font-size: 10px;
+                  font-family: verdana, charcoal, helvetica, arial, sans-serif }
+    p { margin-left: 2em; margin-right: 2em; }
+    li { margin-left: 3em;  }
+    ol { margin-left: 2em; margin-right: 2em; }
+    ul.text { margin-left: 2em; margin-right: 2em; }
+    pre { margin-left: 3em; color: #333333 }
+    ul.toc { color: #000000; line-height: 16px;
+             font-family: verdana, charcoal, helvetica, arial, sans-serif }
+    H3 { color: #333333; font-size: 16px; line-height: 16px; font-family: helvetica, arial, sans-serif }
+    H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, sans-serif }
+    TD.header { color: #ffffff; font-size: 10px; font-family: arial, helvetica, san-serif; valign: top }
+    TD.author-text { color: #000000; font-size: 10px;
+                     font-family: verdana, charcoal, helvetica, arial, sans-serif }
+    TD.author { color: #000000; font-weight: bold; margin-left: 4em; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif }
+     A:link { color: #990000; font-weight: bold;
+              font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
+     A:visited { color: #333333; font-weight: bold;
+                 font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
+     A:name { color: #333333; font-weight: bold;
+              font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
+    .link2 { color:#ffffff; font-weight: bold; text-decoration: none;
+             font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
+             font-size: 9px }
+    .RFC { color:#666666; font-weight: bold; text-decoration: none;
+           font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
+           font-size: 9px }
+    .hotText { color:#ffffff; font-weight: normal; text-decoration: none;
+               font-family: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
+               font-size: 9px }
+</style>
+</head>
+<body bgcolor="#ffffff" text="#000000" alink="#000000" vlink="#666666" link="#990000">
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<table width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table width="100%" border="0" cellpadding="2" cellspacing="1">
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header">IPSECKEY WG</td><td width="33%" bgcolor="#666666" class="header">M. Richardson</td></tr>
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Internet-Draft</td><td width="33%" bgcolor="#666666" class="header">SSW</td></tr>
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Expires: March 4, 2004</td><td width="33%" bgcolor="#666666" class="header">September 4, 2003</td></tr>
+</table></td></tr></table>
+<div align="right"><font face="monaco, MS Sans Serif" color="#990000" size="+3"><b><br><span class="title">A method for storing IPsec keying material in DNS.</span></b></font></div>
+<div align="right"><font face="monaco, MS Sans Serif" color="#666666" size="+2"><b><span class="filename">draft-ietf-ipseckey-rr-07.txt</span></b></font></div>
+<font face="verdana, helvetica, arial, sans-serif" size="2">
+
+<h3>Status of this Memo</h3>
+<p>
+This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.</p>
+<p>
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.
+Note that other groups may also distribute working documents as
+Internet-Drafts.</p>
+<p>
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any time.
+It is inappropriate to use Internet-Drafts as reference material or to cite
+them other than as "work in progress."</p>
+<p>
+The list of current Internet-Drafts can be accessed at
+<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
+<p>
+The list of Internet-Draft Shadow Directories can be accessed at
+<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
+<p>
+This Internet-Draft will expire on March 4, 2004.</p>
+
+<h3>Copyright Notice</h3>
+<p>
+Copyright (C) The Internet Society (2003). All Rights Reserved.</p>
+
+<h3>Abstract</h3>
+
+<p>
+This document describes a new resource record for DNS. This record may be
+used to store public keys for use in IPsec systems. 
+
+</p>
+<p>
+This record replaces the functionality of the sub-type #1 of the KEY Resource
+Record, which has been obsoleted by RFC3445.
+
+</p><a name="toc"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<h3>Table of Contents</h3>
+<ul compact class="toc">
+<b><a href="#anchor1">1.</a>&nbsp;
+Introduction<br></b>
+<b><a href="#anchor2">1.1</a>&nbsp;
+Overview<br></b>
+<b><a href="#anchor3">1.2</a>&nbsp;
+Usage Criteria<br></b>
+<b><a href="#anchor4">2.</a>&nbsp;
+Storage formats<br></b>
+<b><a href="#anchor5">2.1</a>&nbsp;
+IPSECKEY RDATA format<br></b>
+<b><a href="#anchor6">2.2</a>&nbsp;
+RDATA format - precedence<br></b>
+<b><a href="#algotype">2.3</a>&nbsp;
+RDATA format - algorithm type<br></b>
+<b><a href="#gatewaytype">2.4</a>&nbsp;
+RDATA format - gateway type<br></b>
+<b><a href="#anchor7">2.5</a>&nbsp;
+RDATA format - gateway<br></b>
+<b><a href="#anchor8">2.6</a>&nbsp;
+RDATA format - public keys<br></b>
+<b><a href="#anchor9">3.</a>&nbsp;
+Presentation formats<br></b>
+<b><a href="#anchor10">3.1</a>&nbsp;
+Representation of IPSECKEY RRs<br></b>
+<b><a href="#anchor11">3.2</a>&nbsp;
+Examples<br></b>
+<b><a href="#anchor12">4.</a>&nbsp;
+Security Considerations<br></b>
+<b><a href="#anchor13">4.1</a>&nbsp;
+Active attacks against unsecured IPSECKEY resource records<br></b>
+<b><a href="#anchor14">5.</a>&nbsp;
+IANA Considerations<br></b>
+<b><a href="#anchor15">6.</a>&nbsp;
+Acknowledgments<br></b>
+<b><a href="#rfc.references1">&#167;</a>&nbsp;
+Normative references<br></b>
+<b><a href="#rfc.references2">&#167;</a>&nbsp;
+Non-normative references<br></b>
+<b><a href="#rfc.authors">&#167;</a>&nbsp;
+Author's Address<br></b>
+<b><a href="#rfc.copyright">&#167;</a>&nbsp;
+Full Copyright Statement<br></b>
+</ul>
+<br clear="all">
+
+<a name="anchor1"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.1"></a><h3>1.&nbsp;Introduction</h3>
+
+<p>
+   The type number for the IPSECKEY RR is TBD.
+
+</p>
+<a name="rfc.section.1.1"></a><h4><a name="anchor2">1.1</a>&nbsp;Overview</h4>
+
+<p>
+   The IPSECKEY resource record (RR) is used to publish a public key that is
+   to be associated with a Domain Name System (DNS) name for use with the
+   IPsec protocol suite.  This can be the  public key of a host,
+   network, or application (in the case of per-port keying).
+
+</p>
+<p>
+      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
+      "OPTIONAL" in this document are to be interpreted as described in
+      RFC2119 <a href="#RFC2119">[8]</a>.
+
+</p>
+<a name="rfc.section.1.2"></a><h4><a name="anchor3">1.2</a>&nbsp;Usage Criteria</h4>
+
+<p>
+   An IPSECKEY resource record SHOULD be used in combination with DNSSEC
+unless some other means of authenticating the IPSECKEY resource record
+is available.
+
+</p>
+<p>  
+   It is expected that there will often be multiple IPSECKEY resource
+   records at the same name. This will be due to the presence
+   of multiple gateways and the need to rollover keys.
+
+
+</p>
+<p>
+   This resource record is class independent.
+
+</p>
+<a name="anchor4"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.2"></a><h3>2.&nbsp;Storage formats</h3>
+
+<a name="rfc.section.2.1"></a><h4><a name="anchor5">2.1</a>&nbsp;IPSECKEY RDATA format</h4>
+
+<p>
+   The RDATA for an IPSECKEY RR consists of a precedence value, a public key,
+   algorithm type, and an optional gateway address.
+
+</p></font><pre>
+    0                   1                   2                   3  
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  precedence   | gateway type  |  algorithm  |     gateway     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
+   ~                            gateway                            ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               /
+   /                          public key                           /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+
+<a name="rfc.section.2.2"></a><h4><a name="anchor6">2.2</a>&nbsp;RDATA format - precedence</h4>
+
+<p>
+This is an 8-bit precedence for this record. This is interpreted in
+the same way as the PREFERENCE field described in section
+3.3.9 of RFC1035 <a href="#RFC1035">[2]</a>. 
+
+</p>
+<p>
+Gateways listed in IPSECKEY records with  lower precedence are
+to be attempted first. Where there is a tie in precedence, the order
+should be non-deterministic.
+
+</p>
+<a name="rfc.section.2.3"></a><h4><a name="algotype">2.3</a>&nbsp;RDATA format - algorithm type</h4>
+
+<p>
+The algorithm type field identifies the public key's cryptographic
+algorithm and determines the format of the public key field.  
+
+</p>
+<p>
+A value of 0 indicates that no key is present.
+
+</p>
+<p>
+The following values are defined:
+  
+<blockquote class="text"><dl>
+<dt>1</dt>
+<dd>A DSA key is present, in the format defined in RFC2536 <a href="#RFC2536">[11]</a>
+</dd>
+<dt>2</dt>
+<dd>A RSA key is present, in the format defined in RFC3110 <a href="#RFC3110">[12]</a>
+</dd>
+</dl></blockquote><p>
+</p>
+<a name="rfc.section.2.4"></a><h4><a name="gatewaytype">2.4</a>&nbsp;RDATA format - gateway type</h4>
+
+<p>
+The gateway type field indicates the format of the information that
+is stored in the gateway field.
+
+</p>
+<p>
+The following values are defined:
+  
+<blockquote class="text"><dl>
+<dt>0</dt>
+<dd>No gateway is present
+</dd>
+<dt>1</dt>
+<dd>A 4-byte IPv4 address is present
+</dd>
+<dt>2</dt>
+<dd>A 16-byte IPv6 address is present
+</dd>
+<dt>3</dt>
+<dd>A wire-encoded domain name is present. The wire-encoded
+format is self-describing, so the length is implicit. The domain name
+MUST NOT be compressed.
+</dd>
+</dl></blockquote><p>
+</p>
+<a name="rfc.section.2.5"></a><h4><a name="anchor7">2.5</a>&nbsp;RDATA format - gateway</h4>
+
+<p>
+The gateway field indicates a gateway to which an IPsec tunnel may be
+created in order to reach the entity named by this resource record.
+
+</p>
+<p>
+There are three formats:
+
+</p>
+<p>
+A 32-bit IPv4 address is present in the gateway field. The data
+portion is an IPv4 address as described in section 3.4.1 of
+<a href="#RFC1035">RFC1035</a>[2].  This is a 32-bit number in network byte order.
+
+</p>
+<p>A 128-bit IPv6 address is present in the gateway field.
+The data portion is an IPv6 address as described in section 2.2 of
+<a href="#RFC1886">RFC1886</a>[7]. This is a 128-bit number in network byte order.
+
+</p>
+<p>
+The gateway field is a normal wire-encoded domain name, as described
+in section 3.3 of RFC1035 <a href="#RFC1035">[2]</a>. Compression MUST NOT be used. 
+
+</p>
+<a name="rfc.section.2.6"></a><h4><a name="anchor8">2.6</a>&nbsp;RDATA format - public keys</h4>
+
+<p>
+Both of the public key types defined in this document (RSA and DSA)
+inherit their public key formats from the corresponding KEY RR formats. 
+Specifically, the public key field contains the algorithm-specific
+portion of the KEY RR RDATA, which is all of the KEY RR DATA after the
+first four octets.  This is the same portion of the KEY RR that must be
+specified by documents that define a DNSSEC algorithm.  
+Those documents also specify a message digest to be used for generation
+of SIG RRs; that specification is not relevant for IPSECKEY RR.
+
+</p>
+<p>
+Future algorithms, if they are to be used by both DNSSEC (in the KEY
+RR) and IPSECKEY, are likely to use the same public key encodings in
+both records.  Unless otherwise specified, the IPSECKEY public key
+field will contain the algorithm-specific portion of the KEY RR RDATA
+for the corresponding algorithm.  The algorithm must still be
+designated for use by IPSECKEY, and an IPSECKEY algorithm type number
+(which might be different than the DNSSEC algorithm number) must be
+assigned to it.
+
+</p>
+<p>The DSA key format is defined in RFC2536 <a href="#RFC2536">[11]</a>
+</p>
+<p>The RSA key format is defined in RFC3110 <a href="#RFC3110">[12]</a>,
+with the following changes:
+</p>
+<p>
+The earlier definition of RSA/MD5 in RFC2065 limited the exponent and
+modulus to 2552 bits in length.  RFC3110 extended that limit to 4096
+bits for RSA/SHA1 keys.  The IPSECKEY RR imposes no length limit on
+RSA public keys, other than the 65535 octet limit imposed by the
+two-octet length encoding.  This length extension is applicable only
+to IPSECKEY and not to KEY RRs. 
+
+</p>
+<a name="anchor9"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.3"></a><h3>3.&nbsp;Presentation formats</h3>
+
+<a name="rfc.section.3.1"></a><h4><a name="anchor10">3.1</a>&nbsp;Representation of IPSECKEY RRs</h4>
+
+<p>
+   IPSECKEY RRs may appear in a zone data master file.
+   The precedence, gateway type and algorithm and gateway fields are REQUIRED.
+   The base64 encoded public key block is OPTIONAL; if not present,
+   then the public key field of the resource record MUST be construed
+   as being zero octets in length.
+
+</p>
+<p>
+   The algorithm field is an unsigned integer. No mnemonics are defined.
+
+</p>
+<p>
+   If no gateway is to be indicated, then the gateway type field MUST
+   be zero, and the gateway field MUST be "."
+
+</p>
+<p>
+   The Public Key field is represented as a Base64 encoding of the
+   Public Key.  Whitespace is allowed within the Base64 text.  For a
+   definition of Base64 encoding, see
+<a href="#RFC1521">RFC1521</a>[3] Section 5.2.
+
+</p>
+<p>
+   The general presentation for the record as as follows:
+</p>
+</font><pre>
+IN     IPSECKEY ( precedence gateway-type algorithm
+                  gateway base64-encoded-public-key )
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<p>
+
+</p>
+<a name="rfc.section.3.2"></a><h4><a name="anchor11">3.2</a>&nbsp;Examples</h4>
+
+<p> 
+An example of a node 192.0.2.38 that will accept IPsec tunnels on its
+own behalf.
+</p>
+</font><pre>
+38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2 
+                 192.0.2.38
+                 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<p>
+
+</p>
+<p> 
+An example of a node, 192.0.2.38 that has published its key only.
+</p>
+</font><pre>
+38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
+                 .
+                 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<p>
+
+</p>
+<p> 
+An example of a node, 192.0.2.38 that has delegated authority to the node
+192.0.2.3.
+</p>
+</font><pre>
+38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
+                 192.0.2.3
+                 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<p>
+
+</p>
+<p> 
+An example of a node, 192.0.1.38 that has delegated authority to the node
+with the identity "mygateway.example.com".
+</p>
+</font><pre>
+38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
+                 mygateway.example.com.
+                 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<p>
+
+</p>
+<p> 
+An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has
+delegated authority to the node 2001:0DB8:c000:0200:2::1
+</p>
+</font><pre>
+$ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int.
+0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
+                 2001:0DB8:0:8002::2000:1
+                 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+<p>
+
+</p>
+<a name="anchor12"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.4"></a><h3>4.&nbsp;Security Considerations</h3>
+
+<p>
+   This entire memo pertains to the provision of public keying material
+   for use by key management protocols such as ISAKMP/IKE (RFC2407)
+   <a href="#RFC2407">[9]</a>.
+
+</p>
+<p>
+The IPSECKEY resource record contains information that SHOULD be
+communicated to the end client in an integral fashion - i.e. free from
+modification. The form of this channel is up to the consumer of the
+data - there must be a trust relationship between the end consumer of this
+resource record and the server. This relationship may be end-to-end
+DNSSEC validation, a TSIG or SIG(0) channel to another secure source,
+a secure local channel on the host, or some combination of the above.
+
+</p>
+<p>
+The keying material provided by the IPSECKEY resource record is not
+sensitive to passive attacks. The keying material may be freely
+disclosed to any party without any impact on the security properties
+of the resulting IPsec session: IPsec and IKE provide for defense
+against both active and passive attacks.
+
+</p>
+<p>
+   Any user of this resource record MUST carefully document their trust
+   model, and why the trust model of DNSSEC is appropriate, if that is
+   the secure channel used.
+
+</p>
+<a name="rfc.section.4.1"></a><h4><a name="anchor13">4.1</a>&nbsp;Active attacks against unsecured IPSECKEY resource records</h4>
+
+<p>
+This section deals with active attacks against the DNS. These attacks
+require that DNS requests and responses be intercepted and changed.
+DNSSEC is designed to defend against attacks of this kind.
+
+</p>
+<p>
+The first kind of active attack is when the attacker replaces the
+keying material with either a key under its control or with garbage.
+
+</p>
+<p>
+If the attacker is not able to mount a subsequent 
+man-in-the-middle attack on the IKE negotiation after replacing the
+public key, then this will result in a denial of service, as the
+authenticator used by IKE would fail.  
+
+</p>
+<p>
+If the attacker is able to both to mount active attacks against DNS
+and is also in a position to perform a man-in-the-middle attack on IKE and
+IPsec negotiations, then the attacker will be in a position to compromise
+the resulting IPsec channel. Note that an attacker must be able to
+perform active DNS attacks on both sides of the IKE negotiation in
+order for this to succeed. 
+
+</p>
+<p>
+The second kind of active attack is one in which the attacker replaces
+the the gateway address to point to a node under the attacker's
+control. The attacker can then either replace the public key or remove
+it, thus providing an IPSECKEY record of its own to match the
+gateway address. 
+
+</p>
+<p>
+This later form creates a simple man-in-the-middle since the attacker
+can then create a second tunnel to the real destination. Note that, as before,
+this requires that the attacker also mount an active attack against
+the responder. 
+
+</p>
+<p>
+Note that the man-in-the-middle can not just forward cleartext
+packets to the original destination. While the destination may be
+willing to speak in the clear, replying to the original sender,
+the sender will have already created a policy expecting ciphertext.
+Thus, the attacker will need to intercept traffic from both sides. In some
+cases, the attacker may be able to accomplish the full intercept by use
+of Network Addresss/Port Translation (NAT/NAPT) technology.
+
+</p>
+<p>
+Note that the danger here only applies to cases where the gateway
+field of the IPSECKEY RR indicates a different entity than the owner
+name of the IPSECKEY RR.  In cases where the end-to-end integrity of
+the IPSECKEY RR is suspect, the end client MUST restrict its use
+of the IPSECKEY RR to cases where the RR owner name matches the
+content of the gateway field.
+
+</p>
+<a name="anchor14"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.5"></a><h3>5.&nbsp;IANA Considerations</h3>
+
+<p>
+This document updates the IANA Registry for DNS Resource Record Types
+by assigning type X to the IPSECKEY record.  
+
+</p>
+<p>
+This document creates an IANA registry for the algorithm type field.
+
+</p>
+<p>
+Values 0, 1 and 2 are defined in <a href="#algotype">RDATA format - algorithm type</a>. Algorithm numbers
+3 through 255 can be assigned by IETF Consensus (<a href="#RFC2434">see RFC2434</a>[6]).
+
+</p>
+<p>
+This document creates an IANA registry for the gateway type field.
+
+</p>
+<p>
+Values 0, 1, 2 and 3 are defined in <a href="#gatewaytype">RDATA format - gateway type</a>.
+Algorithm numbers 4 through 255 can be assigned by
+Standards Action (<a href="#RFC2434">see RFC2434</a>[6]).
+
+</p>
+<a name="anchor15"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<a name="rfc.section.6"></a><h3>6.&nbsp;Acknowledgments</h3>
+
+<p>
+My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob Austein,
+and Olafur Gurmundsson who reviewed this document carefully.
+Additional thanks to Olafur Gurmundsson for a reference implementation.
+
+</p>
+<a name="rfc.references1"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<h3>Normative references</h3>
+<table width="99%" border="0">
+<tr><td class="author-text" valign="top"><b><a name="RFC1034">[1]</a></b></td>
+<td class="author-text">Mockapetris, P., "<a href="ftp://ftp.isi.edu/in-notes/rfc1034.txt">Domain names - concepts and facilities</a>", STD 13, RFC 1034, November 1987.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC1035">[2]</a></b></td>
+<td class="author-text"><a href="mailto:">Mockapetris, P.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1035.txt">Domain names - implementation and specification</a>", STD 13, RFC 1035, November 1987.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC1521">[3]</a></b></td>
+<td class="author-text"><a href="mailto:nsb@bellcore.com">Borenstein, N.</a> and <a href="mailto:">N. Freed</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1521.txt">MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies</a>", RFC 1521, September 1993.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2026">[4]</a></b></td>
+<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2026.txt">The Internet Standards Process -- Revision 3</a>", BCP 9, RFC 2026, October 1996.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2065">[5]</a></b></td>
+<td class="author-text"><a href="mailto:dee@cybercash.com">Eastlake, D.</a> and <a href="mailto:charlie_kaufman@iris.com">C. Kaufman</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2065.txt">Domain Name System Security Extensions</a>", RFC 2065, January 1997.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2434">[6]</a></b></td>
+<td class="author-text"><a href="mailto:narten@raleigh.ibm.com">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no">H. Alvestrand</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2434.txt">Guidelines for Writing an IANA Considerations Section in RFCs</a>", BCP 26, RFC 2434, October 1998.</td></tr>
+</table>
+
+<a name="rfc.references2"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<h3>Non-normative references</h3>
+<table width="99%" border="0">
+<tr><td class="author-text" valign="top"><b><a name="RFC1886">[7]</a></b></td>
+<td class="author-text"><a href="mailto:set@thumper.bellcore.com">Thomson, S.</a> and <a href="mailto:Christian.Huitema@MIRSA.INRIA.FR">C. Huitema</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1886.txt">DNS Extensions to support IP version 6</a>", RFC 1886, December 1995.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2119">[8]</a></b></td>
+<td class="author-text"><a href="mailto:-">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, March 1997.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2407">[9]</a></b></td>
+<td class="author-text"><a href="mailto:ddp@network-alchemy.com">Piper, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2407.txt">The Internet IP Security Domain of Interpretation for ISAKMP</a>", RFC 2407, November 1998.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2535">[10]</a></b></td>
+<td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2535.txt">Domain Name System Security Extensions</a>", RFC 2535, March 1999.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC2536">[11]</a></b></td>
+<td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2536.txt">DSA KEYs and SIGs in the Domain Name System (DNS)</a>", RFC 2536, March 1999.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC3110">[12]</a></b></td>
+<td class="author-text">Eastlake, D., "<a href="ftp://ftp.isi.edu/in-notes/rfc3110.txt">RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</a>", RFC 3110, May 2001.</td></tr>
+<tr><td class="author-text" valign="top"><b><a name="RFC3445">[13]</a></b></td>
+<td class="author-text">Massey, D. and S. Rose, "<a href="ftp://ftp.isi.edu/in-notes/rfc3445.txt">Limiting the Scope of the KEY Resource Record (RR)</a>", RFC 3445, December 2002.</td></tr>
+</table>
+
+<a name="rfc.authors"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<h3>Author's Address</h3>
+<table width="99%" border="0" cellpadding="0" cellspacing="0">
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">Michael C. Richardson</td></tr>
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">Sandelman Software Works</td></tr>
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">470 Dawson Avenue</td></tr>
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">Ottawa, ON  K1Z 5V7</td></tr>
+<tr><td class="author-text">&nbsp;</td>
+<td class="author-text">CA</td></tr>
+<tr><td class="author" align="right">EMail:&nbsp;</td>
+<td class="author-text"><a href="mailto:mcr@sandelman.ottawa.on.ca">mcr@sandelman.ottawa.on.ca</a></td></tr>
+<tr><td class="author" align="right">URI:&nbsp;</td>
+<td class="author-text"><a href="http://www.sandelman.ottawa.on.ca/">http://www.sandelman.ottawa.on.ca/</a></td></tr>
+</table>
+<a name="rfc.copyright"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
+<h3>Full Copyright Statement</h3>
+<p class='copyright'>
+Copyright (C) The Internet Society (2003). All Rights Reserved.</p>
+<p class='copyright'>
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it
+or assist in its implementation may be prepared, copied, published and
+distributed, in whole or in part, without restriction of any kind,
+provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by removing
+the copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of
+developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be
+followed, or as required to translate it into languages other than
+English.</p>
+<p class='copyright'>
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.</p>
+<p class='copyright'>
+This document and the information contained herein is provided on an
+&quot;AS IS&quot; basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS 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.</p>
+<h3>Acknowledgement</h3>
+<p class='copyright'>
+Funding for the RFC Editor function is currently provided by the
+Internet Society.</p>
+</font></body></html>
diff --git a/doc/src/draft-richardson-ipsec-rr.xml b/doc/src/draft-richardson-ipsec-rr.xml
new file mode 100644
index 000000000..e51b32615
--- /dev/null
+++ b/doc/src/draft-richardson-ipsec-rr.xml
@@ -0,0 +1,560 @@
+<?xml version="1.0"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
+<?rfc toc="yes"?>
+
+<rfc ipr="full2026" docName="draft-ietf-ipseckey-rr-07.txt">
+
+<front>
+  <area>Security</area>
+  <workgroup>IPSECKEY WG</workgroup>
+  <title abbrev="ipsecrr">
+     A method for storing IPsec keying material in DNS.
+  </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>
+
+  <date month="September" year="2003" />
+
+<abstract>
+  <t>
+This document describes a new resource record for DNS. This record may be
+used to store public keys for use in IPsec systems. 
+</t>
+
+<t>
+This record replaces the functionality of the sub-type #1 of the KEY Resource
+Record, which has been obsoleted by RFC3445.
+</t>
+</abstract>
+
+</front>
+
+<middle>
+
+<section title="Introduction">
+<t>
+   The type number for the IPSECKEY RR is TBD.
+</t>
+
+<section title="Overview">
+<t>
+   The IPSECKEY resource record (RR) is used to publish a public key that is
+   to be associated with a Domain Name System (DNS) name for use with the
+   IPsec protocol suite.  This can be the  public key of a host,
+   network, or application (in the case of per-port keying).
+</t>
+
+<t>
+      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
+      "OPTIONAL" in this document are to be interpreted as described in
+      RFC2119 <xref target="RFC2119" />.
+</t>
+</section>
+
+<section title="Usage Criteria">
+<t>
+   An IPSECKEY resource record SHOULD be used in combination with DNSSEC
+unless some other means of authenticating the IPSECKEY resource record
+is available.
+</t>
+
+<t>  
+   It is expected that there will often be multiple IPSECKEY resource
+   records at the same name. This will be due to the presence
+   of multiple gateways and the need to rollover keys.
+
+</t>
+
+<t>
+   This resource record is class independent.
+</t>
+</section>
+</section>
+
+<section title="Storage formats">
+
+<section title="IPSECKEY RDATA format">
+
+<t>
+   The RDATA for an IPSECKEY RR consists of a precedence value, a public key,
+   algorithm type, and an optional gateway address.
+</t>
+
+<artwork><![CDATA[
+    0                   1                   2                   3  
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  precedence   | gateway type  |  algorithm  |     gateway     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
+   ~                            gateway                            ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               /
+   /                          public key                           /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+]]></artwork>
+</section>
+
+<section title="RDATA format - precedence">
+<t>
+This is an 8-bit precedence for this record. This is interpreted in
+the same way as the PREFERENCE field described in section
+3.3.9 of RFC1035 <xref target="RFC1035" />. 
+</t>
+<t>
+Gateways listed in IPSECKEY records with  lower precedence are
+to be attempted first. Where there is a tie in precedence, the order
+should be non-deterministic.
+</t>
+</section>
+
+<section anchor="algotype" title="RDATA format - algorithm type">
+<t>
+The algorithm type field identifies the public key's cryptographic
+algorithm and determines the format of the public key field.  
+</t>
+
+<t>
+A value of 0 indicates that no key is present.
+</t>
+
+<t>
+The following values are defined:
+  <list style="hanging">
+  <t hangText="1">A DSA key is present, in the format defined in RFC2536 <xref target="RFC2536" /></t>
+  <t hangText="2">A RSA key is present, in the format defined in RFC3110 <xref target="RFC3110" /></t>
+  </list>
+</t>
+
+</section>
+
+<section anchor="gatewaytype" title="RDATA format - gateway type">
+<t>
+The gateway type field indicates the format of the information that
+is stored in the gateway field.
+</t>
+
+<t>
+The following values are defined:
+  <list style="hanging">
+  <t hangText="0">No gateway is present</t>
+  <t hangText="1">A 4-byte IPv4 address is present</t>
+  <t hangText="2">A 16-byte IPv6 address is present</t>
+  <t hangText="3">A wire-encoded domain name is present. The wire-encoded
+format is self-describing, so the length is implicit. The domain name
+MUST NOT be compressed.</t>
+  </list>
+</t>
+
+</section>
+
+<section title="RDATA format - gateway">
+<t>
+The gateway field indicates a gateway to which an IPsec tunnel may be
+created in order to reach the entity named by this resource record.
+</t>
+<t>
+There are three formats:
+</t>
+
+<t>
+A 32-bit IPv4 address is present in the gateway field. The data
+portion is an IPv4 address as described in section 3.4.1 of
+<xref target="RFC1035">RFC1035</xref>.  This is a 32-bit number in network byte order.
+</t>
+
+<t>A 128-bit IPv6 address is present in the gateway field.
+The data portion is an IPv6 address as described in section 2.2 of
+<xref target="RFC1886">RFC1886</xref>. This is a 128-bit number in network byte order.
+</t>
+
+<t>
+The gateway field is a normal wire-encoded domain name, as described
+in section 3.3 of RFC1035 <xref target="RFC1035" />. Compression MUST NOT be used. 
+</t>
+
+</section>
+
+<section title="RDATA format - public keys">
+<t>
+Both of the public key types defined in this document (RSA and DSA)
+inherit their public key formats from the corresponding KEY RR formats. 
+Specifically, the public key field contains the algorithm-specific
+portion of the KEY RR RDATA, which is all of the KEY RR DATA after the
+first four octets.  This is the same portion of the KEY RR that must be
+specified by documents that define a DNSSEC algorithm.  
+Those documents also specify a message digest to be used for generation
+of SIG RRs; that specification is not relevant for IPSECKEY RR.
+</t>
+
+<t>
+Future algorithms, if they are to be used by both DNSSEC (in the KEY
+RR) and IPSECKEY, are likely to use the same public key encodings in
+both records.  Unless otherwise specified, the IPSECKEY public key
+field will contain the algorithm-specific portion of the KEY RR RDATA
+for the corresponding algorithm.  The algorithm must still be
+designated for use by IPSECKEY, and an IPSECKEY algorithm type number
+(which might be different than the DNSSEC algorithm number) must be
+assigned to it.
+</t>
+
+<t>The DSA key format is defined in RFC2536 <xref target="RFC2536" /></t>.
+
+<t>The RSA key format is defined in RFC3110 <xref target="RFC3110" />,
+with the following changes:</t>
+
+<t>
+The earlier definition of RSA/MD5 in RFC2065 limited the exponent and
+modulus to 2552 bits in length.  RFC3110 extended that limit to 4096
+bits for RSA/SHA1 keys.  The IPSECKEY RR imposes no length limit on
+RSA public keys, other than the 65535 octet limit imposed by the
+two-octet length encoding.  This length extension is applicable only
+to IPSECKEY and not to KEY RRs. 
+</t>
+
+</section>
+
+</section>
+
+
+
+<section title="Presentation formats">
+
+<section title="Representation of IPSECKEY RRs">
+<t>
+   IPSECKEY RRs may appear in a zone data master file.
+   The precedence, gateway type and algorithm and gateway fields are REQUIRED.
+   The base64 encoded public key block is OPTIONAL; if not present,
+   then the public key field of the resource record MUST be construed
+   as being zero octets in length.
+</t>
+<t>
+   The algorithm field is an unsigned integer. No mnemonics are defined.
+</t>
+<t>
+   If no gateway is to be indicated, then the gateway type field MUST
+   be zero, and the gateway field MUST be "."
+</t>
+
+<t>
+   The Public Key field is represented as a Base64 encoding of the
+   Public Key.  Whitespace is allowed within the Base64 text.  For a
+   definition of Base64 encoding, see
+<xref target="RFC1521">RFC1521</xref> Section 5.2.
+</t>
+
+   
+<t>
+   The general presentation for the record as as follows:
+<artwork><![CDATA[
+IN     IPSECKEY ( precedence gateway-type algorithm
+                  gateway base64-encoded-public-key )
+]]></artwork>
+</t>
+</section>
+
+
+<section title="Examples">
+<t> 
+An example of a node 192.0.2.38 that will accept IPsec tunnels on its
+own behalf.
+<artwork><![CDATA[
+38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2 
+                 192.0.2.38
+                 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+]]></artwork>
+</t>
+
+<t> 
+An example of a node, 192.0.2.38 that has published its key only.
+<artwork><![CDATA[
+38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
+                 .
+                 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+]]></artwork>
+</t>
+
+<t> 
+An example of a node, 192.0.2.38 that has delegated authority to the node
+192.0.2.3.
+<artwork><![CDATA[
+38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
+                 192.0.2.3
+                 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+]]></artwork>
+</t>
+
+<t> 
+An example of a node, 192.0.1.38 that has delegated authority to the node
+with the identity "mygateway.example.com".
+<artwork><![CDATA[
+38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
+                 mygateway.example.com.
+                 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+]]></artwork>
+</t>
+
+<t> 
+An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has
+delegated authority to the node 2001:0DB8:c000:0200:2::1
+<artwork><![CDATA[
+$ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int.
+0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
+                 2001:0DB8:0:8002::2000:1
+                 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+]]></artwork>
+</t>
+
+</section>
+</section>
+
+<section title="Security Considerations">
+<t>
+   This entire memo pertains to the provision of public keying material
+   for use by key management protocols such as ISAKMP/IKE (RFC2407)
+   <xref target="RFC2407" />.
+</t>
+
+<t>
+The IPSECKEY resource record contains information that SHOULD be
+communicated to the end client in an integral fashion - i.e. free from
+modification. The form of this channel is up to the consumer of the
+data - there must be a trust relationship between the end consumer of this
+resource record and the server. This relationship may be end-to-end
+DNSSEC validation, a TSIG or SIG(0) channel to another secure source,
+a secure local channel on the host, or some combination of the above.
+</t>
+
+<t>
+The keying material provided by the IPSECKEY resource record is not
+sensitive to passive attacks. The keying material may be freely
+disclosed to any party without any impact on the security properties
+of the resulting IPsec session: IPsec and IKE provide for defense
+against both active and passive attacks.
+</t>
+
+<t>
+   Any user of this resource record MUST carefully document their trust
+   model, and why the trust model of DNSSEC is appropriate, if that is
+   the secure channel used.
+</t>
+
+<section title="Active attacks against unsecured IPSECKEY resource records">
+<t>
+This section deals with active attacks against the DNS. These attacks
+require that DNS requests and responses be intercepted and changed.
+DNSSEC is designed to defend against attacks of this kind.
+</t>
+
+<t>
+The first kind of active attack is when the attacker replaces the
+keying material with either a key under its control or with garbage.
+</t>
+
+<t>
+If the attacker is not able to mount a subsequent 
+man-in-the-middle attack on the IKE negotiation after replacing the
+public key, then this will result in a denial of service, as the
+authenticator used by IKE would fail.  
+</t>
+
+<t>
+If the attacker is able to both to mount active attacks against DNS
+and is also in a position to perform a man-in-the-middle attack on IKE and
+IPsec negotiations, then the attacker will be in a position to compromise
+the resulting IPsec channel. Note that an attacker must be able to
+perform active DNS attacks on both sides of the IKE negotiation in
+order for this to succeed. 
+</t>
+
+<t>
+The second kind of active attack is one in which the attacker replaces
+the the gateway address to point to a node under the attacker's
+control. The attacker can then either replace the public key or remove
+it, thus providing an IPSECKEY record of its own to match the
+gateway address. 
+</t>
+
+<t>
+This later form creates a simple man-in-the-middle since the attacker
+can then create a second tunnel to the real destination. Note that, as before,
+this requires that the attacker also mount an active attack against
+the responder. 
+</t>
+
+<t>
+Note that the man-in-the-middle can not just forward cleartext
+packets to the original destination. While the destination may be
+willing to speak in the clear, replying to the original sender,
+the sender will have already created a policy expecting ciphertext.
+Thus, the attacker will need to intercept traffic from both sides. In some
+cases, the attacker may be able to accomplish the full intercept by use
+of Network Addresss/Port Translation (NAT/NAPT) technology.
+</t>
+
+<t>
+Note that the danger here only applies to cases where the gateway
+field of the IPSECKEY RR indicates a different entity than the owner
+name of the IPSECKEY RR.  In cases where the end-to-end integrity of
+the IPSECKEY RR is suspect, the end client MUST restrict its use
+of the IPSECKEY RR to cases where the RR owner name matches the
+content of the gateway field.
+</t>
+</section>
+
+</section>
+
+<section title="IANA Considerations">
+<t>
+This document updates the IANA Registry for DNS Resource Record Types
+by assigning type X to the IPSECKEY record.  
+</t>
+
+<t>
+This document creates an IANA registry for the algorithm type field.
+</t>
+<t>
+Values 0, 1 and 2 are defined in <xref target="algotype" />. Algorithm numbers
+3 through 255 can be assigned by IETF Consensus (<xref target="RFC2434">see RFC2434</xref>).
+</t>
+
+<t>
+This document creates an IANA registry for the gateway type field.
+</t>
+<t>
+Values 0, 1, 2 and 3 are defined in <xref target="gatewaytype" />.
+Algorithm numbers 4 through 255 can be assigned by
+Standards Action (<xref target="RFC2434">see RFC2434</xref>).
+</t>
+
+
+
+</section>
+
+<section title="Acknowledgments">
+<t>
+My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob Austein,
+and Olafur Gurmundsson who reviewed this document carefully.
+Additional thanks to Olafur Gurmundsson for a reference implementation.
+</t>
+</section>
+
+</middle>
+
+<back>
+<references title="Normative references">
+<!-- DNSSEC -->
+<?rfc include="reference.RFC.1034" ?>
+<?rfc include="reference.RFC.1035" ?>
+<?rfc include="reference.RFC.1521" ?>
+<?rfc include="reference.RFC.2026" ?>
+<?rfc include="reference.RFC.2065" ?>
+<?rfc include="reference.RFC.2434" ?>
+</references>
+
+<references title="Non-normative references">
+<?rfc include="reference.RFC.1886" ?>
+<?rfc include="reference.RFC.2119" ?>
+<?rfc include="reference.RFC.2407" ?>
+<?rfc include="reference.RFC.2535" ?>
+<?rfc include="reference.RFC.2536" ?>
+<?rfc include="reference.RFC.3110" ?>
+<?rfc include="reference.RFC.3445" ?>
+</references>
+</back>
+</rfc>
+<!--
+  $Id: draft-richardson-ipsec-rr.xml,v 1.1 2004/03/15 20:35:24 as Exp $
+
+  $Log: draft-richardson-ipsec-rr.xml,v $
+  Revision 1.1  2004/03/15 20:35:24  as
+  added files from freeswan-2.04-x509-1.5.3
+
+  Revision 1.23  2003/09/04 23:26:09  mcr
+  	more nits.
+
+  Revision 1.22  2003/08/16 15:55:35  mcr
+  	fixed version to -06.
+
+  Revision 1.21  2003/08/16 15:52:32  mcr
+  	Sam's comments on IANA considerations.
+
+  Revision 1.20  2003/07/27 22:57:54  mcr
+  	updated document with new text about a seperate registry
+  	for the algorithm type.
+
+  Revision 1.19  2003/06/30 01:51:50  mcr
+  	minor typo fixes.
+
+  Revision 1.18  2003/06/16 17:45:00  mcr
+  	adjusted date on rev-04.
+
+  Revision 1.17  2003/06/16 17:41:30  mcr
+  	revision -04
+
+  Revision 1.16  2003/06/16 17:39:20  mcr
+  	adjusted typos, and adjusted IANA considerations.
+
+  Revision 1.15  2003/05/26 19:31:23  mcr
+  	updates to drafts - IPSEC RR - SC versions, and RFC3526
+  	reference in OE draft.
+
+  Revision 1.14  2003/05/23 13:57:40  mcr
+  	updated draft ##.
+
+  Revision 1.13  2003/05/23 13:54:45  mcr
+  	updated month on draft.
+
+  Revision 1.12  2003/05/21 15:42:49  mcr
+  	new SC section with comments from Rob Austein.
+
+  Revision 1.11  2003/05/20 20:52:22  mcr
+  	new security considerations section.
+
+  Revision 1.10  2003/05/20 19:07:47  mcr
+  	rewrote Security Considerations.
+
+  Revision 1.9  2003/05/20 18:17:09  mcr
+  	nits from Rob Austein.
+
+  Revision 1.8  2003/04/29 00:44:59  mcr
+  	updates according to WG consensus: restored three-way
+  	gateway field type.
+
+  Revision 1.7  2003/03/30 17:00:29  mcr
+  	updates according to community feedback.
+
+  Revision 1.6  2003/03/19 02:20:24  mcr
+  	updated draft based upon comments from working group
+
+  Revision 1.5  2003/02/23 22:39:22  mcr
+  	updates to IPSECKEY draft.
+
+  Revision 1.4  2003/02/21 04:39:04  mcr
+  	updated drafts, and added crosscompile.html
+
+  Revision 1.3  2003/01/17 16:26:34  mcr
+  	updated IPSEC KEY draft with restrictions.
+
+  Revision 1.2  2002/08/26 18:20:54  mcr
+  	updated documents
+
+  Revision 1.1  2002/08/10 20:05:33  mcr
+  	document proposing IPSECKEY Resource Record
+
+
+!>
diff --git a/lib/libfreeswan/Makefile b/lib/libfreeswan/Makefile
index b7d4192c8..aa05927e3 100644
--- a/lib/libfreeswan/Makefile
+++ b/lib/libfreeswan/Makefile
@@ -11,7 +11,7 @@
 # or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 # for more details.
 #
-# RCSID $Id: Makefile,v 1.2 2004/03/22 21:53:17 as Exp $
+# RCSID $Id: Makefile,v 1.3 2006/07/06 12:35:32 as Exp $
 
 
 FREESWANSRCDIR=../..
@@ -55,8 +55,10 @@ CFLAGS+= -Wstrict-prototypes
 #CFLAGS+= -W
 #CFLAGS+= -Wwrite-strings
 CFLAGS+= -Wbad-function-cast 
-CFLAGS+= -DNAT_TRAVERSAL
 
+ifeq ($(USE_NAT_TRAVERSAL),true)
+  CFLAGS+= -DNAT_TRAVERSAL
+endif
 
 ARFLAGS=crvs
 EXTHDRS=des.h
diff --git a/programs/Makefile.program b/programs/Makefile.program
index 6868c258a..14d2d8269 100644
--- a/programs/Makefile.program
+++ b/programs/Makefile.program
@@ -22,6 +22,10 @@ endif
 
 #CFLAGS+= ${WERROR}
 
+ifeq ($(USE_NAT_TRAVERSAL),true)
+  CFLAGS+= -DNAT_TRAVERSAL
+endif
+
 ifneq ($(LD_LIBRARY_PATH),)
 LDFLAGS=-L$(LD_LIBRARY_PATH)
 endif
diff --git a/programs/pluto/Makefile b/programs/pluto/Makefile
index 515b3fac0..908060038 100644
--- a/programs/pluto/Makefile
+++ b/programs/pluto/Makefile
@@ -12,7 +12,7 @@
 # or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 # for more details.
 #
-# RCSID $Id: Makefile,v 1.44 2006/01/25 17:22:19 as Exp $
+# RCSID $Id: Makefile,v 1.45 2006/07/06 12:33:08 as Exp $
 
 # relative path to top directory of FreeS/WAN source
 # Note: referenced in ${FREESWANSRCDIR}/Makefile.inc
@@ -108,11 +108,11 @@ ifeq ($(USE_KERNEL26),true)
 endif
 
 ifeq ($(USE_NAT_TRAVERSAL),true)
-NAT_DEFS=-DNAT_TRAVERSAL -DVIRTUAL_IP
+  NAT_DEFS=-DNAT_TRAVERSAL -DVIRTUAL_IP
 endif
 
 ifeq ($(USE_NAT_TRAVERSAL_TRANSPORT_MODE),true)
-NAT_DEFS+=-DI_KNOW_TRANSPORT_MODE_HAS_SECURITY_CONCERN_BUT_I_WANT_IT
+  NAT_DEFS+=-DI_KNOW_TRANSPORT_MODE_HAS_SECURITY_CONCERN_BUT_I_WANT_IT
 endif
 
 DEFINES = $(EXTRA_DEFINES) \
diff --git a/programs/pluto/alg_info.c b/programs/pluto/alg_info.c
index 4ac7f2ca9..af2753312 100644
--- a/programs/pluto/alg_info.c
+++ b/programs/pluto/alg_info.c
@@ -2,7 +2,7 @@
  * Algorithm info parsing and creation functions
  * Author: JuanJo Ciarlante <jjo-ipsec@mendoza.gov.ar>
  *
- * $Id: alg_info.c,v 1.5 2004/09/29 22:42:49 as Exp $
+ * $Id: alg_info.c,v 1.6 2006/08/03 10:18:21 as Exp $
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -192,6 +192,10 @@ aalg_getbyname_esp(const char *const str, int len)
     if (!str || !*str)
 	return -1;
 
+    /* interpret 'SHA' as 'SHA1' */
+    if (strncasecmp("SHA", str, len) == 0)
+	return enum_search(&auth_alg_names, "AUTH_ALGORITHM_HMAC_SHA1");
+
     ret = enum_search_prefix(&auth_alg_names,"AUTH_ALGORITHM_HMAC_", str ,len);
     if (ret >= 0)
 	return ret;
@@ -337,6 +341,10 @@ aalg_getbyname_ike(const char *const str, int len)
     if (!str || !*str)
 	return -1;
 
+    /* interpret 'SHA1' as 'SHA' */
+    if (strncasecmp("SHA1", str, len) == 0)
+	return enum_search(&oakley_hash_names, "OAKLEY_SHA");
+
     ret = enum_search_prefix(&oakley_hash_names,"OAKLEY_", str, len);
     if (ret >= 0)
 	return ret;
diff --git a/programs/pluto/connections.c b/programs/pluto/connections.c
index 6cf6a6a8b..8bd3ed49b 100644
--- a/programs/pluto/connections.c
+++ b/programs/pluto/connections.c
@@ -11,7 +11,7 @@
  * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  * for more details.
  *
- * RCSID $Id: connections.c,v 1.43 2006/04/29 18:16:02 as Exp $
+ * RCSID $Id: connections.c,v 1.44 2006/07/06 19:20:09 as Exp $
  */
 
 #include <string.h>
@@ -116,7 +116,8 @@ find_host_pair(const ip_address *myaddr, u_int16_t myport
 	hisaddr = aftoinfo(addrtypeof(myaddr))->any;
 	
 #ifdef NAT_TRAVERSAL
-    if (nat_traversal_enabled) {
+    if (nat_traversal_enabled)
+    {
 	/**
 	 * port is not relevant in host_pair. with nat_traversal we
 	 * always use pluto_port (500)
@@ -151,9 +152,11 @@ find_host_pair_connections(const ip_address *myaddr, u_int16_t myport
     struct host_pair *hp = find_host_pair(myaddr, myport, hisaddr, hisport);
 
 #ifdef NAT_TRAVERSAL
-    if (nat_traversal_enabled && hp && hisaddr) {
+    if (nat_traversal_enabled && hp && hisaddr)
+    {
 	struct connection *c;
-	for (c = hp->connections; c != NULL; c = c->hp_next) {
+	for (c = hp->connections; c != NULL; c = c->hp_next)
+	{
 	    if ((c->spd.this.host_port==myport) && (c->spd.that.host_port==hisport))
 		return c;
 	}
diff --git a/programs/pluto/keys.c b/programs/pluto/keys.c
index 21092383a..55d13282c 100644
--- a/programs/pluto/keys.c
+++ b/programs/pluto/keys.c
@@ -11,7 +11,7 @@
  * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  * for more details.
  *
- * RCSID $Id: keys.c,v 1.24 2006/01/27 08:59:40 as Exp $
+ * RCSID $Id: keys.c,v 1.25 2006/07/06 19:23:28 as Exp $
  */
 
 #include <stddef.h>
@@ -55,11 +55,6 @@
 #include "timer.h"
 #include "fetch.h"
 
-#ifdef NAT_TRAVERSAL
-#define PB_STREAM_UNDEFINED
-#include "nat_traversal.h"
-#endif
-
 const char *shared_secrets_file = SHARED_SECRETS_FILE;
 
 typedef struct id_list id_list_t;
@@ -186,9 +181,8 @@ get_secret(const struct connection *c, enum PrivateKeyKind kind, bool asym)
 	his_id = &rw_id;
     }
 #ifdef NAT_TRAVERSAL
-    else if (nat_traversal_enabled
+    else if (kind == PPK_PSK
     && (c->policy & POLICY_PSK)
-    && kind == PPK_PSK
     && ((c->kind == CK_TEMPLATE && c->spd.that.id.kind == ID_NONE) ||
         (c->kind == CK_INSTANCE && id_is_ipaddr(&c->spd.that.id))))
     {
diff --git a/programs/pluto/vendor.c b/programs/pluto/vendor.c
index 3a8ac15a9..a51971cde 100644
--- a/programs/pluto/vendor.c
+++ b/programs/pluto/vendor.c
@@ -11,7 +11,7 @@
  * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  * for more details.
  *
- * RCSID $Id: vendor.c,v 1.38 2006/06/04 09:42:35 as Exp $
+ * RCSID $Id: vendor.c,v 1.39 2006/07/06 12:32:41 as Exp $
  */
 
 #include <stdlib.h>
@@ -200,8 +200,10 @@ static struct vid_struct _vid_tab[] = {
 	 */
 	DEC_MD5_VID(STRONGSWAN_4_0_0, "strongSwan 4.0.0")
 	DEC_MD5_VID(STRONGSWAN_4_0_1, "strongSwan 4.0.1")
+	DEC_MD5_VID(STRONGSWAN_4_0_1, "strongSwan 4.0.2")
 
-	DEC_MD5_VID(STRONGSWAN,       "strongSwan 2.7.2")
+	DEC_MD5_VID(STRONGSWAN,       "strongSwan 2.7.3")
+	DEC_MD5_VID(STRONGSWAN_2_7_2, "strongSwan 2.7.2")
 	DEC_MD5_VID(STRONGSWAN_2_7_1, "strongSwan 2.7.1")
 	DEC_MD5_VID(STRONGSWAN_2_7_0, "strongSwan 2.7.0")
 	DEC_MD5_VID(STRONGSWAN_2_6_4, "strongSwan 2.6.4")
diff --git a/programs/pluto/vendor.h b/programs/pluto/vendor.h
index e0c3a5f30..c4ed6d294 100644
--- a/programs/pluto/vendor.h
+++ b/programs/pluto/vendor.h
@@ -11,7 +11,7 @@
  * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  * for more details.
  *
- * RCSID $Id: vendor.h,v 1.33 2006/06/04 09:42:35 as Exp $
+ * RCSID $Id: vendor.h,v 1.34 2006/07/06 12:32:41 as Exp $
  */
 
 #ifndef _VENDOR_H_
@@ -78,9 +78,11 @@ enum known_vendorid {
   VID_STRONGSWAN_2_6_4		= 57,
   VID_STRONGSWAN_2_7_0		= 58,
   VID_STRONGSWAN_2_7_1		= 59,
+  VID_STRONGSWAN_2_7_2		= 60,
 
   VID_STRONGSWAN_4_0_0		= 70,
   VID_STRONGSWAN_4_0_1		= 71,
+  VID_STRONGSWAN_4_0_2		= 72,
 
   /* 101 - 200 : NAT-Traversal */
   VID_NATT_STENBERG_01		=101,
diff --git a/testing/INSTALL b/testing/INSTALL
index 5fc87a6c7..055219ae6 100644
--- a/testing/INSTALL
+++ b/testing/INSTALL
@@ -53,7 +53,7 @@ are required for the strongSwan testing environment:
     * A vanilla Linux kernel on which the UML kernel will be based on.
       We recommend the use of
 
-      http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.1.tar.bz2
+      http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.7.tar.bz2
 
     * Starting with Linux kernel 2.6.9 no patch must be applied any more in order
       to make the vanilla kernel UML-capable. For older kernels you'll find
@@ -71,7 +71,7 @@ are required for the strongSwan testing environment:
 
     * The latest strongSwan distribution
 
-      http://download.strongswan.org/strongswan-2.7.2.tar.gz
+      http://download.strongswan.org/strongswan-2.7.3.tar.gz
 
 
 3. Creating the environment
@@ -146,5 +146,5 @@ README document.
 
 -----------------------------------------------------------------------------
 
-This file is RCSID $Id: INSTALL,v 1.41 2006/06/22 13:07:24 as Exp $
+This file is RCSID $Id: INSTALL,v 1.43 2006/08/03 10:20:54 as Exp $
 
diff --git a/testing/testing.conf b/testing/testing.conf
index dc5c74fbf..4f323d354 100755
--- a/testing/testing.conf
+++ b/testing/testing.conf
@@ -14,14 +14,14 @@
 # or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 # for more details.
 #
-# RCSID $Id: testing.conf,v 1.54 2006/06/22 13:07:24 as Exp $
+# RCSID $Id: testing.conf,v 1.56 2006/08/03 10:20:54 as Exp $
 
 # Root directory of testing
 UMLTESTDIR=~/strongswan-testing
 
 # Bzipped kernel sources
 # (file extension .tar.bz2 required)
-KERNEL=$UMLTESTDIR/linux-2.6.17.1.tar.bz2
+KERNEL=$UMLTESTDIR/linux-2.6.17.7.tar.bz2
 
 # Extract kernel version
 KERNELVERSION=`basename $KERNEL .tar.bz2 | sed -e 's/linux-//'`
@@ -34,7 +34,7 @@ KERNELCONFIG=$UMLTESTDIR/.config-2.6.17
 UMLPATCH=
 
 # Bzipped source of strongSwan
-STRONGSWAN=$UMLTESTDIR/strongswan-2.7.2.tar.bz2
+STRONGSWAN=$UMLTESTDIR/strongswan-2.7.3.tar.bz2
 
 # strongSwan compile options (use "yes" or "no")
 USE_LIBCURL="yes"
diff --git a/testing/tests/alg-sha-equals-sha1/description.txt b/testing/tests/alg-sha-equals-sha1/description.txt
new file mode 100644
index 000000000..aeb2e1a88
--- /dev/null
+++ b/testing/tests/alg-sha-equals-sha1/description.txt
@@ -0,0 +1,5 @@
+Roadwarrior <b>carol</b> proposes to gateway <b>moon</b> the syntactically
+incorrect cipher suites <b>ike=aes128-sha1-modp1536</b> for the
+IKE protocol and <b>esp=aes128-sha</b> for ESP packets. Since <b>sha</b> and
+<b>sha1</b> are treated as synonyms the proposal is neverless correctly parsed.
+A ping from <b>carol</b> to <b>alice</b> successfully checks the established tunnel.
diff --git a/testing/tests/alg-sha-equals-sha1/evaltest.dat b/testing/tests/alg-sha-equals-sha1/evaltest.dat
new file mode 100644
index 000000000..c3656c690
--- /dev/null
+++ b/testing/tests/alg-sha-equals-sha1/evaltest.dat
@@ -0,0 +1,9 @@
+
+carol::ipsec status::home.*STATE_QUICK_I2.*IPsec SA established::YES
+moon::ipsec status::rw.*STATE_QUICK_R2.*IPsec SA established::YES
+moon::ipsec statusall::IKE algorithm newest: AES_CBC_128-SHA-MODP1536::YES
+carol::ipsec statusall::IKE algorithm newest: AES_CBC_128-SHA-MODP1536::YES
+moon::ipsec statusall::ESP algorithm newest: AES_128-HMAC_SHA1::YES
+carol::ipsec statusall::ESP algorithm newest: AES_128-HMAC_SHA1::YES
+carol::ping -c 1 PH_IP_ALICE::64 bytes from PH_IP_ALICE: icmp_seq=1::YES
+
diff --git a/testing/tests/alg-sha-equals-sha1/hosts/carol/etc/ipsec.conf b/testing/tests/alg-sha-equals-sha1/hosts/carol/etc/ipsec.conf
new file mode 100755
index 000000000..c7328faae
--- /dev/null
+++ b/testing/tests/alg-sha-equals-sha1/hosts/carol/etc/ipsec.conf
@@ -0,0 +1,26 @@
+# /etc/ipsec.conf - strongSwan IPsec configuration file
+
+version	2.0	# conforms to second version of ipsec.conf specification
+
+config setup
+	plutodebug="control crypt"
+	crlcheckinterval=180
+	strictcrlpolicy=no
+
+conn %default
+	ikelifetime=60m
+	keylife=20m
+	rekeymargin=3m
+	keyingtries=1
+	ike=aes128-sha1-modp1536!
+	esp=aes128-sha!
+
+conn home
+	left=PH_IP_CAROL
+	leftnexthop=%direct
+	leftcert=carolCert.pem
+	leftid=carol@strongswan.org
+	right=PH_IP_MOON
+	rightsubnet=10.1.0.0/16
+	rightid=@moon.strongswan.org
+	auto=add
diff --git a/testing/tests/alg-sha-equals-sha1/hosts/moon/etc/ipsec.conf b/testing/tests/alg-sha-equals-sha1/hosts/moon/etc/ipsec.conf
new file mode 100755
index 000000000..398c07fa9
--- /dev/null
+++ b/testing/tests/alg-sha-equals-sha1/hosts/moon/etc/ipsec.conf
@@ -0,0 +1,26 @@
+# /etc/ipsec.conf - strongSwan IPsec configuration file
+
+version	2.0	# conforms to second version of ipsec.conf specification
+
+config setup
+	plutodebug="control crypt"
+	crlcheckinterval=180
+	strictcrlpolicy=no
+
+conn %default
+	ikelifetime=60m
+	keylife=20m
+	rekeymargin=3m
+	keyingtries=1
+	leftnexthop=%direct
+	ike=aes128-sha1-modp1536!
+	esp=aes128-sha!
+
+conn rw
+	left=PH_IP_MOON
+	leftcert=moonCert.pem
+	leftid=@moon.strongswan.org
+	leftsubnet=10.1.0.0/16
+	right=%any
+	rightid=carol@strongswan.org
+	auto=add
diff --git a/testing/tests/alg-sha-equals-sha1/posttest.dat b/testing/tests/alg-sha-equals-sha1/posttest.dat
new file mode 100644
index 000000000..c6d6235f9
--- /dev/null
+++ b/testing/tests/alg-sha-equals-sha1/posttest.dat
@@ -0,0 +1,2 @@
+moon::ipsec stop
+carol::ipsec stop
diff --git a/testing/tests/alg-sha-equals-sha1/pretest.dat b/testing/tests/alg-sha-equals-sha1/pretest.dat
new file mode 100644
index 000000000..7d077c126
--- /dev/null
+++ b/testing/tests/alg-sha-equals-sha1/pretest.dat
@@ -0,0 +1,5 @@
+moon::echo 1 > /proc/sys/net/ipv4/ip_forward
+carol::ipsec start
+moon::ipsec start
+carol::sleep 2
+carol::ipsec up home
diff --git a/testing/tests/alg-sha-equals-sha1/test.conf b/testing/tests/alg-sha-equals-sha1/test.conf
new file mode 100644
index 000000000..a6c8f026c
--- /dev/null
+++ b/testing/tests/alg-sha-equals-sha1/test.conf
@@ -0,0 +1,22 @@
+#!/bin/bash
+#
+# This configuration file provides information on the
+# UML instances used for this test
+
+# All UML instances that are required for this test
+#
+UMLHOSTS="moon carol winnetou"
+
+# Corresponding block diagram
+#
+DIAGRAM="m-c-w.png"
+
+# UML instances on which tcpdump is to be started
+#
+TCPDUMPHOSTS=""
+
+# UML instances on which IPsec is started
+# Used for IPsec logging purposes
+#
+IPSECHOSTS="moon carol"
+