+++ /dev/null
-<?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 <character-strings>.
- (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.
-
-
-!>
projects / thirdparty / strongswan.git / blobdiff