2 <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
5 <rfc ipr="full2026" docName="draft-richardson-ipsec-opportunistic-06.txt">
9 <workgroup>Independent submission</workgroup>
10 <title abbrev="opportunistic">
11 A method for doing opportunistic encryption with IKE
14 <author initials="M." surname="Richardson" fullname="Michael C. Richardson">
15 <organization abbrev="SSW">Sandelman Software Works</organization>
18 <street>470 Dawson Avenue</street>
24 <email>mcr@sandelman.ottawa.on.ca</email>
25 <uri>http://www.sandelman.ottawa.on.ca/</uri>
29 <author initials="D.H." surname="Redelmeier"
30 fullname="D. Hugh Redelmeier">
31 <organization abbrev="Mimosa">Mimosa</organization>
38 <email>hugh@mimosa.com</email>
42 <author initials="H." surname="Spencer"
43 fullname="Henry Spencer">
44 <organization abbrev="SP Systems">SP Systems</organization>
47 <street>Box 280 Station A</street>
51 <country>Canada</country>
53 <email>henry@spsystems.net</email>
57 <date month="February" year="2002"></date>
62 This document describes opportunistic encryption using IKE and IPsec.
63 The objective is to allow encryption without any pre-arrangement
64 specific to the pair of gateways involved. Each gateway administrator
65 makes local arrangements to support opportunistic encryption. Once
66 that is done, any two such gateways can communicate securely.
69 There are two large payoffs. First, if many machines must communicate
70 securely, this approach reduces administrative overhead to order N
71 (number of gateways), rather than the N squared cost to configure each
72 tunnel separately. Second, it becomes possible to make secure
73 communication the default, even when the partner is not known in
77 There are naturally some risks and some costs, which are described.
80 This document is offered up as an Informational RFC.
86 <section title="Introduction">
88 <section title="Motivation">
91 The objective of opportunistic encryption is to allow encryption without
92 any pre-arrangement specific to the pair of gateways involved. Each
93 gateway administrator makes local arrangements -- specifically, adds
94 public key information to DNS records -- to support opportunistic
95 encryption and then enables this feature in the nodes' IPsec stack.
96 Once that is done, any two such nodes can communicate securely.
100 This document describes opportunistic encryption as designed and
101 (to date, partially) implemented by the Linux FreeS/WAN project.
102 For project information, see www.freeswan.org.
106 The Internet Architecture Board (IAB) and Internet Engineering Steering Group
107 have taken a strong stand that the Internet should use powerful
108 encryption to provide security and privacy <xref target="RFC1984" />. This project attempts to put
109 this policy into practice by providing practical means to implement them.
113 The project believes that the IPsec protocols are the best chance to
114 do that, because they are standardized, widely available and can often
115 be deployed very easily, without changing hardware or software or
116 retraining of users. However, the extension to opportunistic encryption
117 seems necessary, both to help control administrative overheads and
118 to get IPsec more widely used.
122 The use of "opportunistic encryption" offers the "fax effect". As each person
123 installs one for their own use, it becomes more valuable for their neighbors
124 to install one too, because there's one more person to use it with. The
125 software automatically notices each newly installed box, and doesn't
126 require a network administrator to reconfigure it.
130 This document describes the infrastructure needed to support this effort.
134 The term S/WAN is a trademark of RSA Data Systems, and is used with permission
140 <section title="Types of network traffic">
142 To aid in understand the relationship between security processing and IPsec
143 we divide network traffic into four categories:
144 <list style="hanging">
145 <t hangText="deny"> networks to which traffic is always forbidden</t>
146 <t hangText="permit"> networks to which traffic in the clear is desired</t>
147 <t hangText="opportunistic tunnel"> networks to which encryption should be
148 done if possible, but communication is done in the clear otherwise</t>
149 <t hangText="configured tunnel"> networks to which encryption must be
150 done, and communication is never in the clear</t>
155 This document describes the third category.
156 The first two categories are provided by traditional firewall devices.
157 The fourth category is presently the offering of many Virtual Private
158 Network (VPN) devices.
162 Category one, denied traffic by IP address, requires no authentication.
166 Category two, permitted traffic by IP address, requires no
167 authentication. This is the normal default on the Internet.
171 Category four, encrypt traffic or drop it, requires authentication of the
172 end points. As the number of end points is typically bounded and is typically
173 under the a single authority, arranging for distribution of
174 authentication material, while difficult, does not require any new
178 The mechanism described here provides an additional way to
179 distribute the authentication materials, notably a public key method that does not
180 require deployment of an X.509 based infrastructure.
184 <section title="Peer authentication in Opportunistic Encryption">
187 Opportunistic encryption involves creating tunnels with other nodes that
188 are essentially strangers. This is done without any prior bilateral
190 There is therefore the difficult question of how does one know who one is
194 One possible answer is that one does not know who one is talking to. No useful
195 authentication can be done, so do not even try. This mode of operation has
196 been given the name "anonymous encryption". A man-in-the-middle attack can be
197 used to thwart the privacy of this communication. This would be an active attack.
198 Without peer authentication, there is no way to prevents this kind of attack.
202 Although a useful mode, it is not the goal of this project. It is a useful
203 starting point, but the system should permit additional layers of trust to
204 be built upon this system. In the described system, the anonymous
205 encryption case is what results without DNSSEC. Were anonymous encryption
206 the end goal, simpler methods are available to achieve this goal.
210 However, an essential premise of building private connections with
211 strangers is that datagrams received through these opportunistic tunnels
212 are no more special than datagrams that arrived in the clear.
216 Unlike in a VPN scenario, these datagrams should not be given any special
217 exceptions when it comes to auditing, further authentication or
222 On the outbound side, when initiating opportunistic encryption, it becomes
223 a local matter what to do if one fails to setup a tunnel. It may be that
224 the packet goes out in the clear, or it may be dropped. This is a local
225 configuration matter.
229 In sum, we gain wider privacy (for the Internet at large) at minimal cost:
230 the cost is the need to reassess assumptions about the relationship between
231 IPsec authentication and further local access control.
236 <section title="Use of RFC2119 terms">
238 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
239 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
240 document, are to be interpreted as described in <xref target="RFC2119" />
246 <section title="Overview">
248 <section title="Reference diagram">
250 <figure anchor="networkdiagram" title="Reference Network Diagram">
251 <preamble>The following network diagram is used in the rest of
252 this document as the canonical diagram</preamble>
256 [A]----+----[SG-A]...+....+....[SG-B]-------[B]
258 [D]----+----[SG-D]...+ +....[C] AS3
262 <postamble></postamble>
267 In this diagram, there are four end-nodes: A, B, C and D.
268 There are three gateways, SG-A, SG-B, SG-D. A, D, SG-A and SG-D are part
269 of the same administrative authority. SG-A and SG-D are on two different exit
270 paths from organization 1. SG-B/B is an independent organizations.
271 Nodes Q and R are nodes that are on the Internet. PI is the Public
272 Internet ("The Wild").
277 <section title="Terminology">
280 The following terminology is used in this document:
283 <list style="hanging">
284 <t hangText="security gateway:"> a system that performs IPsec tunnel
285 mode encapsulation/decapsulation. [SGx] in the diagram</t>
286 <t hangText="Alice:"> node [A] in the diagram. When an IP address is needed, this is 192.1.0.65.</t>
287 <t hangText="Bob:"> node [B] in the diagram. When an IP address is needed, this is 192.2.0.66.</t>
288 <t hangText="Carol:"> node [C] in the diagram. When an IP address is needed, this is 192.1.1.67.</t>
289 <t hangText="Dave:"> node [D] in the diagram. When an IP address is needed, this is 192.3.0.68</t>
290 <t hangText="SG-A"> Alice's security gateway. Internally it is 192.1.0.1, externally it is 192.1.1.4.</t>
291 <t hangText="SG-B"> Bob's security gateway. Internally it is 192.2.0.1, externally it is 192.1.1.5.</t>
292 <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>
293 <t hangText="-"> a single dash represents clear-text datagrams</t>
294 <t hangText="="> an equals sign represents phase 2 (IPsec) cipher-text
296 <t hangText="#"> a hash sign represents phase 1 (IKE) cipher-text
298 <t hangText="."> a period represents an untrusted network of unknown
300 <t hangText="configured tunnel:"> Contrast with opportunistic tunnel. A tunnel that
301 is directly/deliberately/hand configured on participating gateways.
302 Configured tunnel are typically given a higher level of
303 trust than opportunistic tunnels.</t>
305 <t hangText="road warrior tunnel:"> a configured tunnel connecting one
306 node with a fixed IP address and one node with a variable IP address.
307 A road warrior (RW) connection must be initiated by the
308 variable node, since the fixed node does not know what the
309 address for the "road warrior" currently is. </t>
311 <t hangText="anonymous encryption:">
312 The process of encrypting a session without any knowledge of who the
313 other parities are. That is, no authentication of identities is done.</t>
315 <t hangText="opportunistic encryption:">
316 The process of encrypting a session with authenticated knowledge of
317 who the other parties are.</t>
319 <t hangText="lifetime:">
320 The negotiated period in seconds (bytes or datagrams) which a security
321 association will remain alive before needing to be re-keyed.</t>
323 <t hangText="lifespan:">
324 The effective time which a security association remains useful. A
325 security association with a lifespan shorter than its lifetime would
326 be removed when no longer needed. A security association with a
327 lifespan longer than its lifetime would need to be re-keyed one or
330 <t hangText="phase 1 SA"> an ISAKMP/IKE security association, sometimes
331 also referred to as a keying channel.</t>
332 <t hangText="phase 2 SA"> an IPsec security association</t>
333 <t hangText="tunnel"> another term for a set of phase 2 SA (one in each direction)</t>
335 <t hangText="NAT"> Network Address Translation
336 (see <xref target="RFC2663" />)</t>
337 <t hangText="NAPT"> Network Address and Port Translation
338 (see <xref target="RFC2663" />)</t>
340 <t hangText="default-free zone">
341 A set of routers that maintain a complete set of routes to
342 all currently reachable destinations. Having such a list, these routers
343 never make use of a default route. A datagram with a destination address
344 not matching any route will be dropped by such a router.
350 <section title="Model of Operation">
353 The Opportunistic Encryption security gateway ("OE gateway") is a regular
354 gateway node as described in <xref target="RFC0791" /> section 2.4 and
355 <xref target="RFC1009" /> with additional capabilities described here and
356 in <xref target="RFC2401" />.
357 The algorithm described here provides a way to determine, for each datagram,
358 whether or not to apply an encrypting tunnel transformation to the
359 datagram. Thus, two important things that must be determined are whether or
360 not to tunnel and, if so, to which destination.
363 The OE gateway must also be capable of responding to other OE gateways as a
367 <section title="Tunnel Authorization">
369 The decision as to whether or not to create a tunnel is determined on a
370 per-destination address basis. Upon receiving a packet with a destination
371 address not recently seen, the OE gateway performs a lookup in DNS for an
372 authorization record (see <xref target="TXT"/>). This record is located using
373 the IP address to perform a search in the in-addr.arpa (IPv4) or ip6.arpa
374 (IPv6) maps. The presence of an authorization record indicates the desire for
375 a tunnel to be formed.
379 <section title="Tunnel End-point discovery">
382 The record further provides the address or name of the
383 end-point which should be used.
386 The record may also provide the public RSA key of the tunnel end point
387 itself. This is provided for efficiency only - if this is not present, then
388 the address or name provided is used to perform a second lookup to find a KEY
392 DNSSEC (<xref target="RFC2535"/>) SHOULD be used to provide origin and
393 integrity protection of the Resource Records involved. Section
394 <xref target="nodnssec"/> documents a restriction on the tunnel end point if DNSSEC
395 signatures are not available for the relevant records.
400 <section title="Caching of authorization results">
402 The OE gateway MUST maintain a list of source/destination pairs for which
403 Opportunistic Encryption has been attempted for a period of time. Successful
404 discovery of a tunnel end point SHOULD result in creation of a new security
405 association bundle between the OE gateway and the discovered tunnel end
410 Failure to discover an appropriate authorization MUST result in creation of a
411 forwarding policy entry to either drop or transmit in the clear future
412 datagrams. This negative cache is necessary so as to avoid repeatedly looking
413 up the same information, a possibly lengthly process.
417 OE gateways MUST time out all cache entries (both positive and negative ones)
418 periodically. This is done both to remove entries which are no longer
419 necessary, and to permit changes in authorization policy to be discovered.
423 </section> <!-- "Model of Operation" -->
425 </section> <!-- "Overview" -->
427 <section title="Specification">
430 The OE gateway is modeled to have a forwarding plane and a control
431 plane. They are connected by a control channel such as PF_KEY.
432 (See <xref target="RFC2367" />)
433 The forwarding plane performs per-datagram operations. The control plane
435 daemon such as ISAKMP/IKE and performs all authorization, authentication and
436 key derivation functions.
439 <section title="Datagram State Machine">
442 Let the OE gateway maintain a collection of objects -- a superset of the
443 Security Policy Database specific in <xref target="RFC2401" />. For
444 each combination of source and destination address, one may find an SPD
445 object in one of six states. Prior to forwarding each datagram, the
446 source and destination addresses are used to pick an entry from the SPD.
447 The SPD then determines how, and if, the packet is forwarded.
449 <section title="Nonexistent policy">
451 If there is no entry found, then this policy applies.
452 An entry is created with an initial state of "Hold policy". A request for
453 keying material is sent to the keying daemon. The datagram is not forwarded,
454 rather it is attached to the SPD entry as the "first" datagram and retained
455 for eventual transmission in a new state.
459 <section title="Hold policy">
461 A request for keying has been previously made. If the interface to the keying
462 system is lossy (PF_KEY, for instance, can be) a mechanism to retransmit the
463 keying request, rate limited to less than 1 request per second SHOULD be
465 The datagram is not forward. The datagram is attached to the SPD entry as the
466 "last" datagram and retained for eventual transmission. If there was
467 previously a datagram so stored, then it is discarded.
470 The retention of the first attempts to avoid waiting for a TCP retransmit,
471 as the first datagram is probably a TCP SYN packet. The retention of the last
472 datagram as well applies to streaming protocols, where it is useful to know
473 how much data has been lost. These are recommendations.
477 <section title="Pass-through policy">
479 The datagram is forwarded using the normal forwarding table. This state is
480 entered only via command from the keying daemon. Upon entering this state,
481 the "first" and "last" datagrams are forwarded.
485 <section title="Deny policy">
487 The datagram is discarded. This state is entered only via command from the
488 keying daemon. Upon entering this state, the "first" and "last" datagrams are
489 discarded. It is a local matter if further datagrams cause ICMP messages
490 to be generated (i.e. ICMP Administratively denied).
494 <section title="Encrypt policy">
496 The datagram is encrypted using the indicated Security Association Database
498 This state is entered only via command from the keying daemon. Upon entering
499 this state, the "first" and "last" datagrams are using the new encrypt policy.
502 If the associated SAD entry expires (due to byte, packet or time limits) then
503 the entry returns to the Hold policy, causing an expire message to
504 communicated to the keying daemon.
508 All states may be created directly by the keying daemon while acting as a
512 </section> <!-- "Datagram State Machine" -->
515 <section anchor="initclasses" title="Keying State Machine - Initiator">
517 Let the keying daemon maintain a collection of objects -- let them be
518 called "connections" (or "conn"s for short). There are two categories of
519 connection objects: classes and instances. A class connection represents an
520 abstract policy - what could be. An instance represents an actual connection,
521 what is in fact implemented at the time.
525 Let there be two further subtypes of connections: keying channels (aka Phase
526 1 SAs) and data channels (aka Phase 2 SAs). Each data channel object may have
527 a corresponding SPD and SAD entry maintained by the Datagram State Machine.
531 For the purposes of Opportunistic Encryption, there MUST at least be
532 connection classes known as "deny", "always-clear-text", "OE-permissive",
534 The later two connection classes defines a set of source and/or destination
535 addresses for which Opportunistic Encryption will be attempted. There are a
536 number of additional places where the administrator MAY set policy
537 options. An implementation MAY create additional connection classes so that
538 these policies may be enacted in a more fine grained fashion.
542 {should the additional classes be given names here? - ed.} <!-- XXX -->
546 The simplest system may need only the "OE-permissive" connection, and would
547 list its own (single) IP address as the source address of this policy, and
548 the wild-card address 0.0.0.0/0 as the destination IPv4 address. That is, the
549 simplest policy is to try Opportunistic Encryption with all destinations.
553 The distinction between permissive and paranoid OE use will become clear
554 in the state transition differences. In general, a permissive OE will, on
555 failure, install a pass-through policy, while a paranoid OE will, on failure,
556 install a drop policy.
560 In this description of the keying machines state transitions, the states
561 associated with the keying system itself are omitted. This is done for two
562 reasons: they are best documented in the keying system
563 (<xref target="RFC2407" />,
564 <xref target="RFC2408" /> and <xref target="RFC2409" /> for ISAKMP/IKE),
565 and the details are keying system specific. Opportunistic Encryption is not
566 dependent upon any specific keying protocol, but this document does provide
567 requirements for those using ISAKMP/IKE to assure inter-operability.
570 The state transitions that may be involved in communicating with the
571 forwarding plane are omitted. PF_KEY and similar protocols have their own
572 state of states required for message sends and completion notifications.
575 Finally, the retransmits and recursive lookups that are normal for DNS are
576 not included in this state machine.
579 <section title="Nonexistent connection">
581 There is no connection for a given source/destination address pair.
582 Upon receipt of a request for keying material for this particular
583 source/destination pair, a search is made through the connection classes to
584 determine the most appropriate policy. Upon determining an appropriate
585 connection class, then an instance object is created of that type.
586 Both of the OE types results in a Potential OE connection.
588 <t>Failure to find an appropriate connection class results in an
589 administrator defined default.
592 In each case, when an appropriate class is found for the new flow
593 then an instance connection is made of the type which matched.
597 <section title="clear-text connection">
599 A transition is made from the empty connection to this state when an
600 instance of the always-clear-text class is instantiated, or when an OE-permissive
601 connection fails. During the transition, a pass-through policy object is created in the
602 forwarding plane for the appropriate flow.
605 The only way to leave this state is due to a timeout; see expiry connection.
609 <section title="Deny connection">
611 A transition is made from the empty connection to this state when an
612 instance of the deny class is instantiated, or when an OE-paranoid connection fails.
613 During the transition, a deny policy object is created in the forwarding plane
614 for the appropriate flow.
617 The only way to leave this state is due to a timeout; see expiry connection.
621 <section title="Potential OE connection">
623 A transition is made from the empty connection to this state when an
624 instance of either OE class is instantiated.
625 During the transition to this state, a hold policy object is created in the
626 forwarding plane for the appropriate flow.
629 In addition, when transitioning into this state, DNS lookup(s) are done in
630 the reverse map for a TXT delegation resource record. (see <xref target="TXT" />)
631 The destination address of the flow is used as the lookup key.
634 There are three ways to exit this state: due a timeout in the DNS lookup, and
635 via positive or negative replies as to the existence of the TXT delegation
639 If there is a resource record found, and it is properly formatted, and if
640 DNSSEC is enabled - the signature has been vouches for (either through local
641 confirmation or via trusted path to a recursive DNSSEC server), then there is
642 a transition to the Pending OE connection state. (Note that if the public key
643 is not presented in the TXT delegation record, then it must be looked up as
644 well as a sub-state. The DNS lookups are not considered a success until all
645 have completed successfully)
648 If there is no resource record found, or DNS times out then it is to be
649 considered that this is not an OE capable receiver. If this was an
650 OE-paranoid instance, then there is a transition to the deny connection.
651 If this was an OE-permissive instance, then there is a transition to the
652 clear-text connection.
655 If the resource record is found but is misformed, or if DNSSEC has been
656 enabled and reports a failure to authenticate, then there should be a
657 transition to the deny connection. This fact should be logged. If the
658 administrator wishes to override this, then an always-clear class can be
659 installed for this flow. An implementation MAY make this situation a new
662 <section anchor="nodnssec" title="Restriction on unauthentication TXT delegation records">
664 An implementation SHOULD also provide an additional administrative control
665 on delegation records and DNSSEC. This control would apply to delegation
666 records (the TXT records in the reverse map) that are not protected by
668 Records of this type are only permitted to delegate to their own address as
669 a gateway. When this option is enabled, an active attack on DNS will be
670 unable to redirect packets to other than the original destination.
671 <!-- This was asked for by Bill Sommerfeld -->
676 <section title="Pending OE connection">
678 A transition is made from the Potential OE connection to this state when
679 it has been determined that we have all the information from DNS we would need, and
680 should make an attempt to do keying for this connection. Upon entering this
681 state, an attempt to initiate keying to the gateway provided is started.
684 One exits from this state either with a successfully created IPsec SA, or
685 with a failure of some kind. Successful SA creation results in a transition
686 to the Key connection state.
689 There are three failures which are distinguished. They are clearly not the
690 only possible failures from keying, but these are the ones that have caused
694 Note that if there were multiple gateways available in the TXT delegation
695 records, then a failure can only be declared after all have been
696 tried. Further, creation of a phase 1 SA does not constitute success - a set
697 of phase 2 SAs (a tunnel) is considered success.
700 The first failure is when an ICMP port unreachable is consistently received
701 without any other communication, or when there is silence from the remote
702 end. This likely means that the gateway is either not alive, or that the
703 keying daemon is not functional. For an OE-permissive connection, transition
704 to the clear-text connection, but with a rather low lifespan. The gateway may
705 be in the process of rebooting, etc. For an OE-pessimistic connection,
706 transition to the deny connection, again with a low lifespan.
709 How long is long enough to wait for the remote keying daemon to wake up is
710 a matter of some debate. 5 minutes is usually long enough for the network to
711 reconverge if there is a routing failure. Many systems can reboot in that
712 time as well. However, 5 minutes is far too long for most users to wait to
713 hear that they can not connect with OE. Implementations SHOULD make this a
717 If a phase 1 SA is created, but there is either no response to the phase 2
718 proposal, or a negative notify (the notify must be authenticated) is
719 received, then the remote gateway is not prepared to do OE at this time. As
720 before transition to clear-text/deny based upon connection class, but this
721 time with a normal lifespan.
724 The third type of failure is when there is signature failure authenticating
725 the remote gateway. In this case, again transition to clear-text/deny based
726 upon the connection class, but make the timeout depend upon the remaining
727 time to live in the DNS. (Note that DNSSEC signed resource records have a different
728 expiry time from non-signed records) One possibility is that there has been a
729 key roll-over, but that DNS has not caught up.
730 <!-- dig @gateway would also work here -->
735 <section anchor="keyed" title="Keyed connection">
737 A transition is made from the Pending OE connection to this state when
738 session keying material (aka the phase 2 SA) has been formed. An Encrypt
739 Policy is created in the forwarding plane for this flow.
742 There are three ways to exit this state. The first is by receipt of an
743 authenticated delete message (via the keying channel) from the peer. This is
744 normal teardown, and results in a transition to Expired connection.
747 The second way is by expiry of the forwarding plane keying material. This
748 causes a re-key operation to be started with a transition back to Pending OE
749 connection. In general, the soft expiry will occur with sufficient time left
750 for the keys to continue to be used. Note that a re-key can fail, which may
751 result in the connection failing to clear-text or deny as
752 appropriate. Note that the forwarding plane policy does not change until the
753 rekeying attempt has failed or succeeded.
756 The third way is via respond to a negotiation from a remote gateway, via
757 receipt of a indication from the forwarding plane of having received unknown
758 SPI from the gateway, or an ICMP from the remote gateway indicating an
759 unknown SPI. Each of these things should be considered a hint that the remote
760 gateway has rebooted or restarted. Since these can easily be forged, care
761 muyst be exercised. A cautious (rate-limited) attempt to re-key the
762 connection should be done.
766 <section anchor="expiring" title="Expiring connection">
768 Each of the deny, clear-text, and keyed connections will periodically be
769 placed into this sub-state. See <xref target="teardown" /> for more details
770 of how often this occurs.
771 The forwarding plane is queried for last use time of the appropriate
772 policy. If the use time is relatively recent, then the state returns to the
773 previous deny, clear-text or keyed connection state. If not, then it enters
774 the expired connection state.
777 The DNS query and answer that lead to the state in question is also
778 examined. It may have become stale. (A negative, i.e. no such record answer
779 is valid for the period of time given by the MINIMUM field in an attached SOA
780 record. See <xref target="RFC1034" /> section 4.3.4)
781 If it has become stale, then a new query is made. If a change
782 in the results are seen, then a transition to a new state is made as
783 described in Potential OE connection state.
786 Note that both outgoing SPD and incoming SAD must be queried as some flows
787 may be unidirectional for some time.
790 Note that the policy at the forwarding plane is not updated unless there
791 is a conclusion that there should be a change.
795 <section title="Expired connection state">
797 Entry to this state is due to no datagrams being forwarded recently via the
798 appropriate SPD and SAD objects. The objects in the forwarding plane are
799 removed (logging any final byte and packet counts if appropriate) and the
800 connection instance in the keying plane is deleted.
803 An ISAKMP/IKE Delete is sent to clean up the phase 2 SAs as described in
804 <xref target="teardown" />.
807 A difficult question has been whether or not to also delete the phase 1 SAs
808 at this time. This is left as a local implementation issue. Implementations
809 that do delete the phase 1 SAs MUST send authenticated Delete messages to
810 indicate that they are doing so. There is some advantage to simply keeping
811 the phase 1 SAs around until they expire - they may prove useful again in the
816 </section> <!-- "Keying State Machine - Initiator" -->
818 <section title="Keying State Machine - Responder">
820 The responder has an identical set of objects as the initiator.
823 The responder gets its first indication that something is happening when it
824 receives an invitation to create a keying channel from an initiator.
827 <section title="Unauthenticated OE peer state">
829 Upon entering this state, a DNS lookup is done for a KEY record for the
831 This is done in the reverse map for a KEY record for the initiator if the
832 initiator has offered an ID_IPV4_ADDR, and in the forward map if the
833 initiator has offered an ID_FQDN type. (See <xref target="RFC2407" /> section
837 This state is exited upon successful receipt of a KEY from DNS, and use of it
838 to verify the signature of the initiator.
843 The public key that is retrieved should be stored in stable storage for an
844 administratively defined period of time, (typically several months if
845 possible). If a key has previously been stored on disk, then the returned key
846 should be compared to what has been received, and the key considered valid
852 Successful authentication of the peer results in a transition to
853 Authenticated OE Peer.
856 Note that this state generally occurs in the middle of the key negotiation
857 protocol. It is really a form of pseudo-state.
861 <section title="Authenticated OE Peer">
863 The peer will eventually propose one or more phase 2 SAs. The source and
864 destination address in the proposal are used to initialize the still empty
865 connection state using the connection class table.
866 A search for an identical connection object MUST be made at this point.
870 If an identical connection is found, then delete the old instance that had
872 and transition this new object to the Pending OE connection state. This means
873 that new ISAKMP connections with a given peer will always use the latest
874 instance, which is the correct one if the peer has rebooted in the interim.
877 If an identical connection is not found, then transition according to the
878 rules given for the initiator.
881 Note that if the initiator is in OE-paranoid mode and the responder is in
882 either always-clear-text or deny, then no communication is possible according
883 to policy. An implementation is permitted to create new types of policies,
884 such as "accept OE, but do not initiate it". This is a local matter.
888 </section> <!-- "Keying State Machine - Responder" -->
890 <section anchor="teardown" title="Renewal and Teardown">
891 <section title="Aging">
893 A potentially unlimited number of tunnels may exist. In practice, only a few
895 are used during a period of time. Unused tunnels MUST therefore be
896 torn down. Detecting when they are no longer in use is the subject of this section.
900 There are two methods in which the tunnel may be removed: by expiring
901 or with explicit deletion.
905 Explicit deletion is done with an IKE Delete message. To do this requires
906 that both ends maintain the key channel (phase 1 ISAKMP SA), as the deletes
907 MUST be authenticated. An implementation which refuses to either maintain or
908 recreate the keying channel SA will be unable to use this method.
912 In the expiry method, the tunnel is simply allowed by the IKE daemon to
913 expire normally, without attempting to re-key it.
917 Regardless of which method is used, a method is required to determine if the
918 tunnel is still in use. This is a local matter, but the following criteria
919 are what is used by the FreeSWAN project. This criteria is currently
920 implemented in the key management daemon, but could also be implemented at
921 the SPD layer using an idle timer.
923 <list style="hanging">
924 <t hangText="+"> a short initial (soft) lifespan of 1 minute is set. This is
925 done since many net flows in fact last only a few seconds.</t>
927 <t hangText="+"> at the end of the lifespan, a check is made to see if the
928 tunnel was used by traffic in either direction during the last half of
929 this period. If so, assign a longer tentative lifespan, of
930 20 minutes, after which, look again. If the tunnel is not in
931 use then close the tunnel.
935 These timeouts are implemented by the Expiring state in the key management
936 system (see <xref target="expiring" />).
937 The timer given above may in fact be present in the forwarding plane,
938 but it must, in this case be resettable.
942 The tentative lifespan is independent of re-keying; it is just the time when
943 the tunnel's future is next considered.
944 (The term lifespan is used here rather than lifetime for this reason.)
945 This should happen reasonably frequently, unlike re-keying, which is
946 costly and shouldn't be too
950 A multi-step back-off algorithm is not considered worth the effort here.
954 If the security gateway and the client host are one and the
955 same (and not a Bump-in-the-Stack or Bump-in-the-Wire implementation), tunnel
956 teardown decisions MAY pay attention to TCP connection status, as reported
957 by the local TCP layer.
958 A still-open TCP connection is almost a guarantee that more traffic is
959 coming, while the demise of the only TCP connection through a tunnel is a
960 strong hint that no more traffic will transit.
963 </section> <!-- "Aging" -->
965 <section title="Teardown and Cleanup">
968 Teardown should always be coordinated with the other end.
969 This means interpreting and sending Delete notifications. There is some
970 detailed state in the Expired Connection state of the key manager that
971 relates to retransmits of the Delete notifications, but this is considered to
972 be a keying system detail.
976 On receiving a Delete for the outbound SAs of a tunnel (or some subset of
977 them), tear down the inbound ones too, and notify the other end with a
978 Delete. If a Delete is received for a tunnel which is no longer in
979 existence, then two Delete messages have crossed paths. Ignore the Delete -
980 the operation has already been done. Do not generate any messages in this
984 Tunnels need to be considered as bidirectional entities, even though the
985 low-level protocols don't think of them that way.
989 When the deletion is initiated locally, rather than as a
990 response to a received Delete, send a Delete for (all) the
991 inbound SAs of a tunnel. If no responding Delete is
992 received for the outbound SAs, try re-sending the original
993 Delete. Three tries spaced 10s apart seems a reasonable
994 level of effort. A failure for the other end to respond at this point
995 likely indicates that no further communication will be possible in any case.
996 (Likely, it was a mobile node and it is not present or powered on anymore)
1000 After re-keying, transmission should switch to using the new
1001 outgoing SAs (ISAKMP or IPsec) immediately, and the old leftover SAs
1002 should be cleared out promptly (and Deletes sent) rather
1003 than waiting for them to expire. This reduces clutter and
1004 minimizes confusion for the operator doing diagnostics.
1011 </section> <!-- "Specification" -->
1013 <section title="Impacts on IKE">
1015 <section title="ISAKMP/IKE protocol">
1017 The IKE wire protocol needs no modifications. The major changes are
1018 implementation issues relating to how the proposals are interpreted, and from
1022 As Opportunistic Encryption is designed to be useful between peers without
1023 prior operator configuration, an IKE daemon must be prepared to negotiate
1024 phase 1 SAs with any node. This may require a large amount of resources to
1025 maintain cookie state, as well as large amounts of entropy to for nonces,
1029 The major changes to support Opportunistic Encryption are at the IKE daemon
1030 level. These changes relate to handling of key acquisition requests, lookup
1031 of public keys and TXT records, and interactions with firewalls and other
1032 security facilities that may be coresident on the same gateway.
1036 <section title="Gateway discovery process">
1038 In a typical configured tunnel situation, the address of SG-B is provided
1039 via configuration. Furthermore, the mapping of SPD entry to gateway is
1040 typically a 1:1 mapping. When the 0.0.0.0/0 SPD entry technique is used, then
1041 the mapping to a gateway is determined by the reverse DNS records.
1044 The need to do a DNS lookup and wait for a reply will typically introduce a
1045 new state and a new event source (DNS replies) to IKE. Although a synchronous
1046 DNS request can be done for proof of concept, this will not scale very well.
1049 Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with
1050 protocol some steps.
1054 <section title="Self identification">
1056 SG-A will have to establish its identity. This is done by use of an
1059 <t> There are many situations where the administrator of SG-A may not be
1060 able to control the reverse DNS records for SG-A's public IP address.
1061 Typical situations include
1062 dialup connections and most residential-type broadband Internet access
1063 (ADSL, cable-modem). In these situations, a fully qualified domain
1064 name which is under the control of SG-A's administrator may be used
1065 when acting as an initiator only.
1066 The FQDN ID should be used in phase 1. See <xref target="fqdn" />
1067 for more details and restrictions.
1071 <section title="Public key Retrieval process">
1073 Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID, or
1074 an FQDN ID, an IKE daemon will need to examine local caches and
1075 configuration files to determine if this is part of a configured tunnel.
1076 If none is found, then the implementation should attempt to retrieve
1077 a KEY record from the reverse DNS (in the case of an IPv4/IPv6 ID), or
1078 from the forward DNS in the case of FQDN ID.
1081 It is reasonable that if other non-local sources of policy are used
1082 (COPS, LDAP, ...) that they be consulted concurrently, but that some
1083 clear ordering of policy be provided. Note that due to variances in
1084 latency, one must wait for positive or negative replies from all sources
1085 of policy before making any decisions.
1089 <section title="Interactions with DNSSEC">
1091 The present implementation does not use DNSSEC to explicitly verify
1092 the authenticity of zone information, or use the NXT records to provide
1093 authentication of the absence of a TXT or KEY record. These are
1094 important considerations for practical use.
1097 In practice the verification of the DNSSEC SIG and NXT records will
1098 typically be done by a trusted DNS server. This process may be
1099 co-located, or reachable via a trusted path.
1105 <section title="Interactions with COPS">
1107 At this time there is no experience with implementations that interact
1108 with COPS Policy Decision Points (PDP) <xref target="RFC2748" />. It is
1109 suggested that it may be
1110 appropriate for many of
1111 the policy and discovery mechanisms outlined here to be done by a PDP.
1112 In this context, the IKE daemon present in the Policy Enforcement Point
1113 (PEP) may not need any modifications.
1118 <section title="Recommended proposal types">
1120 <section anchor="phase1id" title="Phase 1 parameters">
1122 Main mode MUST be used.
1125 The initiator MUST offer at least one proposal using some combination
1126 of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be
1128 <xref target="MODPGROUPS" />
1131 The initiator MAY offer additional proposals, but the cipher MUST not
1132 be weaker than 3DES. The initiator SHOULD limit the number of proposals
1133 such that the IKE datagrams do not need to be fragmented.
1136 The responder MUST accept one of the proposals. If any configuration
1137 of the responder is required then the responder is not acting in an
1141 SG-A SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6), of the external
1142 interface of SG-A for phase 1. (There is an exception, see <xref
1143 target="fqdn" />) The authentication method MUST be RSA public key signatures.
1146 The RSA key for SG-A MUST be placed into a DNS KEY record in
1147 the reverse space of SG-A. (i.e. using in-addr.arpa.)
1151 <section anchor="phase2id" title="Phase 2 parameters">
1153 SG-A MUST propose a tunnel between Alice and Bob, using 3DES-CBC
1154 mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be specified.
1157 Tunnel mode MUST be used.
1160 Authorization for SG-A to act on Alice's behalf is determined by
1161 looking for a TXT record in the reverse map at Alice's address.
1164 Compression SHOULD NOT be mandatory. It may be offered as an option.
1171 <section title="DNS issues">
1172 <section anchor="KEY" title="Use of KEY record">
1174 In order to establish their own identity, SG-A and SG-B must publish
1175 their public keys in their reverse DNS. This is just done via
1176 DNSSEC's KEY record.
1177 See section 3 of <xref target="RFC2535">RFC 2535</xref>.
1180 <preamble>For example:</preamble>
1182 KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
1185 <list style="hanging">
1186 <t hangText="0x4200"> The flag bits, indicating that this key is prohibited
1187 for use confidentiality (it authenticates the peer only, DH is used for
1188 confidentiality), and that this key is associated with the non-zone entity
1189 whose name is the RR owner name. No other flags are set.</t>
1190 <t hangText="4">This indicates that this key is for use by IPsec</t>
1191 <t hangText="1">An RSA key is present</t>
1192 <t hangText="AQNJjkKlIk9...nYyUkKK8">the public key of the host as described in <xref target="RFC3110" /></t>
1197 <section anchor="TXT" title="Use of TXT delegation record">
1199 A TXT record is published by Alice (Bob) to provide authorization
1200 for SG-A (SG-B) to act on its behalf. This record is located in the
1201 reverse DNS (in-addr.arpa) for Alice's IP address.
1202 The reverse DNS SHOULD be secured by DNSSEC, when it is
1203 deployed. DNSSEC is required to defend against active attacks.
1207 If Alice's address is P.Q.R.S, then she can authorize another node to
1208 act on her behalf by publishing records at:
1210 S.R.Q.P.in-addr.arpa
1215 The contents of the resource record are expected to be a string that
1216 follows the following syntax, as suggested in <xref target="RFC1464" />.
1217 (Note that the reply to query may include other TXT resource records from
1218 other applications may also be returned.)
1220 <figure anchor="txtformat" title="Format of reverse delegation record">
1222 X-IPsec-Server(P)=A.B.C.D KEY
1227 <list style="hanging">
1228 <t hangText="P:"> the P specifies a precedence for this record. This is
1229 similar to MX record preferences. Lower numbers have stronger
1233 <t hangText="A.B.C.D:"> specifies the IP address of the Security Gateway
1234 for this client machine.
1237 <t hangText="KEY:"> is the encoded RSA Public key of the Security
1238 Gateway. This is provided here to avoid a second DNS lookup. If this
1239 field is absent, then a KEY resource record should be looked up in the
1240 reverse map of A.B.C.D.
1245 In the case where Alice is located at a public address behind a
1246 security gateway that has no fixed address (or no control over its
1247 reverse map), then Alice may delegate to a public key by domain name:
1249 <figure anchor="txtfqdnformat"
1250 title="Format of reverse delegation record (FQDN version">
1252 X-IPsec-Server(P)=@FQDN KEY
1257 <list style="hanging">
1258 <t hangText="P:"> is as above.
1261 <t hangText="FQDN"> specifies the FQDN that the Security Gateway
1262 will identify itself with. Only useful for initiator.
1265 <t hangText="KEY:"> is the encoded RSA Public key of the Security
1270 If there is more than one such TXT record with strongest (lowest
1271 numbered) precedence, one Security Gateway is picked arbitrarily from
1272 those specified in the strongest-preference records.
1275 <section title="Choice of TXT record">
1277 It has been suggested to use the OPT, CERT, KEY or KX records instead of
1280 <t> The KEY RR has a Protocol field which could be used to indicate use
1281 for a new protocol, and an Algorithm field which could be used to
1282 indicate different contents in the key data. However, the KEY record
1283 is not clearly intended for storing what are really authorizations,
1284 it is just for identities. Other uses have been discouraged.
1286 <t> OPT resource records, as defined in <xref target="RFC2671" /> are not
1287 intended to be used for storage of information. They are not to be loaded,
1288 cached or forwarded. They are therefore inappropriate for use here.
1291 CERT records <xref target="RFC2538" /> can encode almost any set of
1292 information. A custom Type code would be used permitting any suitable
1293 encoding to be stored, not just X.509. The certificate RR, according to
1294 the RFC, are to be signed internally, which may add undesirable and unnecessary
1295 bulk. Larger DNS records may require TCP transfers instead of UDP ones.
1298 At the time of protocol design, the CERT RR was not widely deployed and
1299 could not be counted upon. Use of CERT records will be investigated,
1300 and may result in a future revision of this document.
1303 KX records are ideally suited for this use, but had not been deployed at
1304 the time of implementation.
1305 <!-- Jakob Schlyter <j@crt.se> to confirm -->
1310 <section anchor="fqdn" title="Use of FQDN IDs">
1312 Unfortunately, not every administrator has control over the contents
1313 of the reverse-map. The only case where we can work around this is
1314 where the initiator (SG-A) has no suitable reverse map. In this case, the
1315 authorization record present in the reverse map of Alice may refer to a
1316 FQDN instead of an IP address.
1319 In this case, the client's TXT record gives the fully qualified domain
1320 name (FQDN) in place of its security gateway's IP address.
1321 The initiator should use the ID_FQDN ID-payload in phase 1.
1322 A forward lookup for a KEY record on the FQDN must yield the
1323 initiator's public key.
1326 This method can also be used when the external address of SG-A is
1330 If SG-A is acting on behalf of Alice, then Alice must still delegate
1331 authority for SG-A to do so in her reverse map. When Alice and SG-A
1332 are one and the same (i.e. Alice is acting as an end-node) then there
1333 is no need for this when initiating only. Alice must still delegate to
1334 herself if she wishes to others to initiator OE to her.
1335 See <xref target="txtfqdnformat" />
1341 <section title="Key rollover">
1343 Good crypto hygiene says that one should replace public/private key pairs
1344 periodically. Some may wish to do this as often as daily. Typical DNS
1345 propogation delays are determined by the SOA Resource Record MINIMUM
1346 parameter, which controls how long DNS replies may be cached. For reasonable
1347 operation of DNS servers, one usually wants this value to be at least several
1348 hours, sometimes as a long as a day. This presents a problem - a new key MUST
1349 not be used prior to it propogating through DNS.
1352 This problem is dealt with by having the Security Gateway generate a new
1353 public/private key pair at least MINIMUM seconds in advance of using it. It
1354 then adds this key to the DNS (both as a second KEY record and to any TXT
1355 delegation records) at key generation time.
1358 When authenticating, all gateways MUST have available all public keys
1359 that are found in DNS for this entity. This permits the authenticating end
1360 to check both the key for "today" and the key for "tomorrow". Note that it is
1361 the end which is creating the signature (possessed the private key) that
1362 determines which key is to be used.
1367 <section title="Network Address Translation interaction">
1369 There are no fundamentally new issues for getting opportunistic encryption
1370 to work in the presence of network address translation. Rather there are
1371 just the regular IPsec issues with NAT traversal.
1374 There are several situations to consider for NAT:
1376 <section title="Colocated NAT/NAPT">
1378 If SG-A is also performing Network Address Translation on
1379 behalf of Alice, then the packet should be translated prior to
1380 being subjected to opportunistic encryption. This is in contrast to
1381 typical configured tunnel which often exist to bridge islands of
1382 private network address space. SG-A will use the translated source
1383 address for phase 2, and so SG-B will look that address up to
1384 confirm SG-A's authorization.
1386 <t> In the case of NAT (1:1), the address space into which the
1387 translation is done MUST be globally unique, and control over the
1388 reverse map is assumed to be a given.
1389 Placing of TXT records is possible.
1391 <t> In the case of NAPT (m:1), the address will be SG-A. The ability to get
1392 KEY and TXT records in place will again depend upon whether or not
1393 there is administrative control over the reverse map. This is
1394 identical situations involving a single host acting on behalf of
1397 FQDN style can be used to get around a lack of a reverse map for
1402 <section title="SG-A behind NAT/NAPT">
1404 If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec
1405 NAT traversal rules would apply. In addition to the transport problem
1406 which can be solved via proposals like <xref target="ESPUDP" />, there
1407 is the issue of what phase 1 and phase 2 IDs to use. While FQDN could
1408 be used during phase 1 for SG-A. An appropriate ID for phase 2
1410 to determine that SG-A was in fact authorized to speak for Alice.
1413 This is only possible if Alice actually has a public IP. It is a
1415 unusual case where a public network exists behind SG-A,
1416 while SG-A itself is behind a NAPT. This may occur with mobile networks
1417 of various kinds that occasionally wind up behind a NAPT.
1421 <section title="Bob is behind a NAT/NAPT">
1423 If Bob is behind a NAT (perhaps SG-B), then there is in fact no way for
1424 Alice to address a packet to Bob. Not only is opportunistic encryption
1425 impossible, but it is also impossible for Alice to initiate any
1426 communication to Bob. It may be possible for Bob to initiate in such
1432 <section title="Host implementations">
1434 When Alice and SG-A are components of the same system, then this is
1435 considered to be a host implementation. The scenario remains unchanged
1436 with respect to packet sequence.
1439 Components marked Alice are simply the upper layers (TCP, UDP, the
1440 application), and SG-A is the IP layer.
1443 Note that tunnel mode is still recommended.
1446 As Alice/SG-A are acting on behalf of themselves, no TXT based delegation
1447 record is necessary for Alice to initiate. She can rely on a FQDN in a
1449 To respond, Alice/SG-A will still need an entry in her reverse map.
1453 <section title="Multihoming">
1455 If there are multiple paths between Alice and Bob (such as illustrated in
1456 the diagram with SG-D) then additional DNS records are required to establish
1460 In the diagram in <xref target="networkdiagram" />, Alice has two ways to
1461 exit her network: SG-A and SG-D. Previously SG-D has been ignored. Postulate
1462 that there are routers between Alice and her set of security gateways
1463 (denoted by the + signs and the marking of an autonomous system number for
1464 Alice's network). Datagrams may therefore travel to either SG-A or SG-D en
1468 As long as all network connections are in good order it does not matter how
1469 datagrams exit Alice's network. When they reach either security gateway, the
1470 security gateway will find the TXT delegation record in Bob's reverse map,
1471 and establish an SA with SG-B.
1474 SG-B has no problem establishing that either of SG-A or SG-D may speak for
1475 Alice, as Alice has published two equally weighted TXT delegation records:
1476 <figure anchor="txtmultiexample" title="Multiple gateway delegation example">
1478 X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
1479 X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
1484 Alice's routers can now happily do any kind of load sharing that they might
1485 wish to do. SG-A and SG-D will both send datagrams addressed to Bob through
1486 their tunnel to SG-B.
1489 If Alice wishes to prefer one gateway over another, then Bob should, upon
1490 finding that he has connections to two gateways en route to Alice, prefer the
1491 most recently established one - the precedence values are only valid for an
1492 initiator. It may be that the other one has experienced a failure, which is
1493 why Alice has switch to her less favourable backup.
1496 If the precedences are the same, then SG-B has a more difficult time. It
1497 must decide which of the two tunnels to use. SG-B has no information about
1498 which link is less loaded, nor which security gateway has more cryptographic
1499 resources available. SG-B in fact has no knowledge of whether both gateways
1503 The Public Internet's default free zone may well know a good route to Alice,
1504 but the datagrams that SG-B creates must be addressed to either SG-A or SG-D;
1505 they can not be addressed to Alice directly.
1508 There are a number of choices which SG-B may make:
1509 <list style="numbers">
1510 <t>It can ignore the problem and round robin among the tunnels it has. This
1511 will cause losses during times when one or the other security gateway is
1512 unreachable. If this worries Alice, she can change the weights in her
1513 TXT delegation records.</t>
1515 <t>It can always send to the gateway that it most recently received from.
1516 This assumes that routing and reachability is symmetrical.</t>
1518 <t>It can listen to BGP information from the Internet to decide which
1519 system is currently up. This is clearly a much more complicated thing
1520 to do, but if SG-B is already doing this because it is participating
1521 in the BGP peering system to announce Bob, the results data may already
1522 be available to it. </t>
1524 <t>It can refuse to negotiate the second tunnel. (It is unclear whether or
1525 not this is even an option)</t>
1527 <t>It can silently replace the outgoing portion of the first tunnel with the
1528 second one, while still retaining the incoming portions of both. SG-B can
1529 thus be willing willing to accept datagrams from either SG-A or SG-D, but
1530 sending only to the gateway that most recently rekeyed with it.</t>
1535 These are decisions left to local policy. Note that even if SG-B has perfect
1536 knowledge about reachability of SG-A and SG-D, Alice may not be reachable
1537 from one or other of these security gateways due to internal reachability
1542 FreeS/WAN implements option 5. Consideration to implementing a different in
1543 being given. The multihoming aspects of this OE, not well developed and may
1544 be a subject of a future document.
1549 <section title="Failure modes">
1550 <section title="DNS failures">
1552 If a DNS server fails to respond, then it is a local policy decision
1553 whether or not to permit communication in the clear. This is emboddied in
1554 the connection classes in <xref target="initclasses" />. It should be
1555 clear that mounting a denial of service attack on the DNS server
1556 responsible for a particular network's reverse map is an easy thing to do.
1557 Such an attack may cause all communication with that network to go in
1558 the clear for a permissive policy, and for communication to fail completely
1559 if this is a paranoid policy. Please note that this is an active attack.
1562 At the same time, there are still a very large number of networks
1563 that do not have properly configured reverse maps. Further, the effect of
1564 the above denial of service attack, if the policy is not to communicate,
1565 is that the target network becomes isolated. This is why this decision MUST
1566 be a matter of local policy.
1570 <section title="DNS configured, IKE failures">
1572 In this situation, DNS records claim that opportunistic encryption should
1573 occur, but the target gateway either does not respond on port 500, or
1574 refuses the proposal. This may be due to a crash/reboot, due to
1575 misconfiguration, or a firewall filtering port 500.
1578 The receipt of ICMP port,
1579 host or network unreachable messages should be taken as a sign that there
1580 is a potential problem, but MUST NOT cause communication to fail
1581 immediately. ICMP messages are easily forged by attackers. If such a
1582 forgery caused immediate failure, then an attacker could easily prevent any
1583 encryption from ever occuring, possibly preventing all communication.
1586 It is recommended that in these situations that a clear log be produced
1587 about the problem. A local policy should dictate if communication is then
1588 permitted in the clear at this point.
1592 <section title="System reboots">
1594 Tunnels sometimes go down because the other end crashes, or
1595 disconnects, or has a network link break, and there is no
1596 notice of this in the general case. (Even in the event of a
1597 crash and successful reboot, other SGs don't hear about it
1598 unless the rebooted SG has specific reason to talk to them
1599 immediately.) Over-quick response to temporary network out-
1600 ages is undesirable... but note that a tunnel can be torn
1601 down and then re-established without any user-visible effect
1602 except a pause in traffic, whereas if one end does reboot,
1603 the other end can't get datagrams to it at all (except via
1604 IKE) until the situation is noticed. So a bias toward quick
1605 response is appropriate, even at the cost of occasional
1610 A mechanism for recover after reboot is not specified in this
1611 document as it is a topic of current research.
1615 A deliberate shutdown should include an attempt to notify all other SGs
1616 currently connected by phase 1 SAs, using Deletes, that communication is
1617 about to fail. (Again, these will be taken as teardowns; attempts by the
1618 other SGs to negotiate new tunnels as replacements should be ignored at
1619 this point.) And when possible, SGs should attempt to preserve
1620 information about currently-connected SGs in non-volatile storage, so
1621 that after a crash, an Initial-Contact can be sent to previous partners to
1622 indicate loss of all previously established connections.
1629 <section title="Performance Experiences">
1631 Claudia> Is it useful to point out (or to clarify for our own discussion) any of the
1634 Claudia> * how much time this is likely to take on typical current hardware?
1635 Claudia> * what steps are likely to be time consuming
1636 Claudia> * how any added time could affect a typical transaction, such as hitting
1638 Claudia> * any ways to minimize such time delays
1640 <section title="Introduced latency">
1643 <section title="Cryptographic performance">
1646 <section title="Phase 1 SA performance">
1652 <section title="Unresolved issues">
1653 <section title="Control of reverse DNS">
1655 The method of obtaining information is by reverse DNS lookup causes
1656 problems for people who can not control their reverse DNS
1657 bindings. This is an unresolved problem in this version, and is out
1663 <section title="Examples">
1665 <section title="Clear-text usage (permit policy)">
1668 What follows are two example scenarios. The first is where Gate1 and Gate2
1669 have always-cleartext policies, and the second where they have some OE
1673 <figure anchor="regulartiming" title="Timing of regular transaction">
1675 Alice Gate1 DNS Gate2 Bob
1676 Alice Gate1 DNS Gate2 Bob
1678 ------(2)-------------->
1679 <-----(3)---------------
1681 ----------(6)------>
1684 <----------(9)------
1687 ----------(12)----->
1690 <-------------------
1696 Alice wants to send a packet to Bob, say a ping packet.
1697 Without the presence of opportunistic encryptors, the following events occur:
1698 <list style="hanging">
1699 <t hangText="(1)">Human or application 'clicks' with a name</t>
1700 <t hangText="(2)">Application looks up name in DNS to get IP address</t>
1701 <t hangText="(3)">Resolver returns A record to application</t>
1702 <t hangText="(4)">Application starts a TCP session or UDP session, OS sends packet</t>
1703 <t hangText="(5)">Packet is seen at first gateway from Alice (SG-A) (Gate1
1704 transitions through Empty connection to always-clear connection and
1705 instantiates a passthrough policy at the forwarding plane)</t>
1706 <t hangText="(6)">Packet is seen at last gateway before Bob (SG-B)</t>
1707 <t hangText="(7)">First packet from Alice is seen by Bob</t>
1708 <t hangText="(8)">First return packet is sent by Bob</t>
1709 <t hangText="(9)">Packet is seen at Bob's gateway (Gate2 transitions through
1710 an Empty connection to always-clear connection and instantites a passthrough
1711 policy at the forwarding plane)</t>
1712 <t hangText="(10)">Packet is seen at Alice's gateway</t>
1713 <t hangText="(11)">OS hands packet to application, Alice sends another packet</t>
1714 <t hangText="(12)">a second packet traverses the Internet</t>
1719 <section title="Opportunistic Encryption">
1722 In the presence of properly configured opportunistic encryptors, the
1723 event list is extended.
1725 <figure anchor="opportunistictiming" title="Timing of Opportunistic Encryption transaction">
1727 Alice SG-A DNS SG-B Bob
1729 ------(2)-------------->
1730 <-----(3)---------------
1734 -------------(5D)--->
1735 <------------(5E1)---
1736 -------------(5E2)-->
1737 <------------(5E3)---
1738 #############(5E4)##>
1739 <############(5E5)###
1742 #############(5G1)##>
1745 <############(5G2)###
1746 #############(5G3)##>
1747 ============(6)====>
1750 <==========(9)======
1753 ==========(12)=====>
1756 <===================
1761 <list style="hanging">
1762 <t hangText="(1)">Human or application clicks with a name</t>
1763 <t hangText="(2)">Application initiates DNS mapping.</t>
1764 <t hangText="(3)">resolver returns A record to application</t>
1765 <t hangText="(4)">Application starts a TCP session or UDP</t>
1766 <t hangText="(5)">SG (host or SG) sees packet to target, buffers it.</t>
1767 <t hangText="(5B)">SG asks the DNS for TXT record</t>
1768 <t hangText="(5C)">DNS returns TXT record(s)</t>
1769 <t hangText="(5D)">Initial IKE Main Mode Packet goes out</t>
1770 <t hangText="(5E)">IKE ISAKMP phase 1 succeeds</t>
1771 <t hangText="(5F)">SG-B asks the DNS for TXT record to prove SG-A agent for Alice</t>
1772 <t hangText="(5G)">IKE phase 2 negotiation</t>
1773 <t hangText="(5H)">DNS looksup by responder (SG-B)</t>
1774 <t hangText="(6)">buffered packet is sent by SG-A</t>
1775 <t hangText="(7)">packet is received by SG-B, and decrypted, sent to Bob</t>
1776 <t hangText="(8)">Bob replies, packet is seen by SG-B</t>
1777 <t hangText="(9)">SG-B already has tunnel up with SG-A, uses it</t>
1778 <t hangText="(10)">SG-A decrypts packet and give it to Alice</t>
1779 <t hangText="(11)">Alice receives packet. Sends new packet to Bob</t>
1780 <t hangText="(12)">SG-A gets second packet, sees that tunnel is up, uses it</t>
1785 For the purposes of this section, we will describe on the changes that
1786 occur between <xref target="regulartiming" /> and
1787 <xref target="opportunistictiming" />. This means time points 5, 6, 7, 9 and 10.
1790 <section title="(5) IPsec packet interception">
1793 At point (5), Security Gateway 1 intercepts the packet due to the
1794 lack of a policy (the non-existant policy!) for this source/destination
1795 pair. A hold policy is created, and the packet is buffered. A request is
1796 sent to the keying daemon for keys.
1801 <section title="(5B) DNS lookup for TXT record">
1803 SG-A's IKE daemon, having looked up the source/destination in the connection
1804 class list, creates a new Potential OE connection instance. The DNS
1805 queries are started.
1809 <section title="(5C) DNS returns TXT record(s)">
1812 DNS returns properly formed TXT delegation records, and SG-A's IKE daemon
1813 transitions this instance from Potential OE connection to Pending OE
1818 For the example above, the returned record might contain:
1820 <figure anchor="txtexample" title="Example of reverse delegation record">
1822 X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
1825 with SG-B's IP address and public key listed.
1830 <section title="(5D) Initial IKE Main Mode Packet goes out">
1831 <t>Upon entering Pending OE connection, SG-A sends the initial ISAKMP
1832 message, with proposals, see <xref target="phase1id" />.
1836 <section title="(5E1) Message 2 of phase 1 exchange">
1838 SG-B receives the message. A new connection instance is created in the
1839 Unauthenticated OE Peer state.
1843 <section title="(5E2) Message 3 of phase 1 exchange">
1845 SG-A sends a Diffie-Hellman exponent. This is an internal state of the
1850 <section title="(5E3) Message 4 of phase 1 exchange">
1852 SG-B responds with a Diffie-Hellman exponent. This is an internal state of the
1857 <section title="(5E4) Message 5 of phase 1 exchange">
1859 SG-A uses the phase 1 SA to send its identity under encryption.
1860 The choice of identity is discussed in <xref target="phase1id" />.
1861 This is an internal state of the keying protocol.
1865 <section title="(5F1) Responder lookup of initiator key">
1867 Security Gateway 2 asks DNS for the public key of the initiator.
1868 This is done by asking for a KEY record by IP address in the reverse map.
1869 That is, a KEY resource record is queried for 4.1.1.192.in-addr.arpa
1870 (recall that SG-A's external address is 192.1.1.4)
1871 The resulting public key is used to authenticate the initiator. See <xref
1872 target="KEY" /> for further details.
1876 <section title="(5F2) DNS replies with public key of initiator">
1878 Upon successfully authenticating the peer, the connection instance is
1879 transitioned to Authenticated OE peer on SG-2.
1882 The format of the TXT record that is returned is described in
1883 <xref target="TXT" />.
1887 <section title="(5E5) Responder replies with ID and authentication">
1889 SG-B sends its ID along with authentication material. This is an internal
1890 state for the keying protocol.
1894 <section title="(5G) IKE phase 2">
1895 <section title="(5G1) Initiator proposes tunnel">
1897 Having established mutually agreeable authentications (via KEY) and
1898 authorizations (via TXT), SG-A proposes to create an IPsec tunnel for
1899 datagrams transiting from Alice to Bob. This tunnel is established for only
1900 the A/B combination, not for any subnets that may be behind SG-A and SG-B.
1904 <section title="(5H1) Responder determines initiator's authority">
1906 While the identity of the SG-A has been established, its authority to
1907 speak for Alice has not yet been confirmed. This is done by doing a reverse
1908 lookup on A's address for a TXT record.
1910 <t>Upon receiving this specific proposal, SG-2 transitions its instance
1911 into the Potential OE connection state. SG-2 may already have an
1912 instance, and the check is made as described above.</t>
1915 <section title="(5H2) DNS replies with TXT record">
1917 The returned key and IP address should match that of SG-A.
1921 <section title="(5G2) Responder agrees to proposal">
1923 Should additional communication occur between, for instance, D and B via
1924 SG-A and SG-B, a new tunnel (phase 2 SA) would be established. The phase 1 SA
1927 <t>SG-A, having successfully keyed the tunnel, now transitions from
1928 Pending OE connection to Keyed OE connection.
1930 <t>The responder MUST setup inbound IPsec SAs before sending its reply.</t>
1933 <section title="(5G3) Final acknowledgement from initiator">
1935 The initiator agrees with the responder's choice and sets up the tunnel.
1936 The initiator sets up inbound and outbound IPsec SAs.
1939 The proper authorization returned with keys SG-2 to transition its instance
1940 to the Keyed OE connection.
1942 <t>Upon receipt of this message, the responder may now setup the outbound
1947 <section title="(6) IPsec succeeds, sets up tunnel for communication between Alice and Bob">
1949 The packet which was saved at step (5) is sent through the newly created
1950 tunnel to SG-B. Bob receives it at (7) and replies at (8).
1954 <section title="(9) SG-B already has tunnel up with G1, uses it">
1956 At (9), SG-B has already established an SPD entry mapping Bob->Alice via a
1957 tunnel, so this tunnel is simply applied. The packet is encrypted to SG-A,
1958 decrypted by SG-A and passed to Alice at (10).
1962 </section> <!-- OE example -->
1964 </section> <!-- Examples -->
1966 <section anchor="securityconsiderations" title="Security Considerations">
1968 <section title="Configured vs Opportunistic Tunnels">
1970 Configured tunnels are those which are setup using bilateral mechanisms: exchanging
1971 public keys (raw RSA, DSA, PKIX), pre-shared secrets, or by referencing keys that
1972 are in known places (distinguished name from LDAP, DNS). These keys are then used to
1973 configure a specific tunnel.
1976 A pre-configured tunnel may be on all the time, or may be keyed only when needed.
1977 The end points of the tunnel are not necessarily static: many mobile
1978 applications ("road warrior") are considered to be configured tunnels.
1981 The primary consideration is that configured tunnels are assigned specific
1982 security properties. They may be trusted in different ways. This is usually
1983 related to exceptions to firewall rules, exceptions to NAT processing, and to
1984 bandwidth or other quality of service restrictions.
1987 Opportunistic tunnels are not inherently trusted in any strong way. They are
1988 created without prior arrangement. As the two parties are strangers, there
1989 MUST be no confusion of datagrams that arrive from opportunistic peers and
1990 those that arrive from configured tunnels. A security gateway MUST take care
1991 that an opportunistic peer can not impersonate a configured peer.
1994 Ingress filtering MUST be used to make sure that only packets authorized by
1995 negotiation (and the concomitant authentication and authorization) are
1996 accepted from a tunnel. This is to prevent one peer from impersonating another.
1999 An implementation suggestion is to logically treat opportunistically tunnel
2000 datagrams as if they arrive on a distinct logical interface from other
2001 configured tunnels. As the number of opportunistic tunnels that may be
2002 created automatically on a system is potentially very high, careful attention
2003 to scaling should be taken into account.
2006 As with any IKE negotiation, opportunistic encryption cannot be secure
2007 without authentication. Opportunistic encryption relies on DNS for its
2008 authentication information and therefore cannot be fully secure without
2009 a secure DNS. Without secure DNS, it can protect against passive
2010 eavesdropping, but not against active man-in-the-middle attacks.
2014 <section title="Firewalls vs Opportunistic Tunnels">
2016 Typical usage of per-packet access control lists is to implement various
2017 kinds of security gateways. These are typically called "firewalls".
2020 Typical usage of virtual private network (VPN) within a firewall is to
2021 bypass all or part of the access controls between two networks. Additional
2022 trust (as outlined in the previous section) is given to datagrams that arrive
2026 Datagrams that arrive via opportunistically configured tunnels MUST not be
2027 trusted. Any security policy that would apply to a packet arriving in the
2028 clear SHOULD also be applied to datagrams arriving opportunistically.
2032 <section title="Denial of Service">
2034 There are several different forms of denial of service which an implementor
2035 should concern themselves with. Most of these problems are shared with
2036 security gateways that have large numbers of mobile peers (road warriors).
2039 The design of ISAKMP/IKE, and its use of cookies, defend against many kinds
2040 of denial of service. There is an assumption that if the phase 1 (ISAKMP)
2041 SA is authenticated, that it was worthwhile creating. Opportunism changes
2042 this assumption. As the gateway will communicate with anyone, it is
2043 possible to form phase 1 SAs with any machine on the Internet.
2049 <section title="IANA Considerations">
2051 There are no known numbers which IANA will need to manage.
2055 <section title="Acknowledgements">
2057 Thanks to Tero Kivinen, Sandy Harris, Wes Hardarker, Robert Moskowitz,
2058 Jakob Schlyter, Bill Sommerfeld, John Gilmore and John Denker for their
2059 comments and constructive criticism.
2067 %include.reference.OEspec;
2068 <!-- renumber according to reference order -->
2069 %include.reference.RFC.0791;
2070 %include.reference.RFC.1009;
2071 %include.reference.RFC.1984;
2072 %include.reference.RFC.2119;
2074 %include.reference.RFC.2367;
2075 %include.reference.RFC.2401;
2076 %include.reference.RFC.2407;
2077 %include.reference.RFC.2408;
2078 %include.reference.RFC.2409;
2080 %include.reference.ESPUDP;
2082 %include.reference.MODPGROUPS;
2084 %include.reference.RFC.1034;
2085 %include.reference.RFC.2671;
2086 %include.reference.RFC.1464;
2087 %include.reference.RFC.2535;
2088 %include.reference.RFC.3110;
2089 %include.reference.RFC.2538;
2091 %include.reference.RFC.2748;
2093 %include.reference.RFC.2663;
2098 $Id: draft-richardson-ipsec-opportunistic.xml,v 1.17 2002/03/12 21:23:55 mcr Exp $
2100 $Log: draft-richardson-ipsec-opportunistic.xml,v $
2101 Revision 1.17 2002/03/12 21:23:55 mcr
2102 adjusted definition of default-free zone.
2103 moved text on key rollover from format description to new
2106 Revision 1.16 2002/02/22 01:23:21 mcr
2107 revisions from MCR (2002/2/18) and net.
2109 Revision 1.15 2002/02/21 20:44:12 mcr
2112 Revision 1.14 2002/02/10 16:20:39 mcr
2113 -05 draft. Many revisions to do "OE system in world of OE systems"
2114 view of the universe.
2116 Revision 1.13 2001/12/20 04:35:22 mcr
2117 fixed reference to rfc1984.
2119 Revision 1.12 2001/12/20 03:35:19 mcr
2120 comments from Henry, Tero, and Sandy.
2122 Revision 1.11 2001/12/19 07:26:22 mcr
2123 added comment about KX records.
2125 Revision 1.10 2001/11/09 04:28:10 mcr
2126 fixed some typos with XML, and one s/SG-B/SG-D/.
2128 Revision 1.9 2001/11/09 04:07:13 mcr
2129 expanded section 10: multihoming, with an example.
2131 Revision 1.8 2001/11/09 02:16:51 mcr
2132 added lifetime/lifespan definitions.
2133 moved example from 5B to 5C.
2134 added reference to phase 1 IDs to 5D.
2135 cleared up text in aging section.
2136 added text about delegation of DNSSEC activity to a DNS server.
2137 spelt out DH group names.
2138 added text about ignoring TXT records unless DNSSEC is deployed (somerfeld)
2139 added example of TXT delegation using FQDN.
2140 clarified some text in NAT interaction section.
2141 clarified absense of TXT record need for host implementation
2143 Revision 1.7 2001/11/08 23:09:37 mcr
2144 changed revision of draft to 03.
2146 Revision 1.6 2001/11/08 19:37:14 mcr
2147 fixed some formatting of Aging section.
2149 Revision 1.5 2001/11/08 19:19:30 mcr
2150 fixed address for DHR, updated address for MCR,
2151 added reference to original HS/DHR OE specification paper.
2153 Revision 1.4 2001/11/08 19:08:24 mcr
2154 section 10, "Renewal and Teardown" added moved between 4/5, and
2157 Revision 1.3 2001/11/08 18:56:34 mcr
2158 sections 4.2, 5.6, 5.7.1 and 6.2 edited as per HS.
2159 section 10, "Renewal and Teardown" added.
2160 section 11, "Failure modes" completed.
2162 Revision 1.2 2001/11/05 20:31:31 mcr
2163 added section from OE spec on aging and teardown.
2165 Revision 1.1 2001/11/05 04:27:58 mcr
2166 OE draft added to documentation.
2168 Revision 1.12 2001/10/10 01:12:31 mcr
2169 removed impact on DNS servers section.
2170 removed nested comments.
2171 adjusted data of issue
2173 Revision 1.11 2001/09/17 02:55:50 mcr
2174 outline is now stable.
2176 Revision 1.5 2001/08/19 02:53:32 mcr
2177 version 00d formatted.
2179 Revision 1.10 2001/08/19 02:34:04 mcr
2180 version 00d formatted.
2182 Revision 1.9 2001/08/19 02:21:54 mcr
2185 Revision 1.8 2001/07/20 19:07:06 mcr
2186 commented out section 1.1
2188 Revision 1.7 2001/07/20 14:14:22 mcr
2191 Revision 1.6 2001/07/19 00:56:50 mcr
2194 Revision 1.5 2001/07/12 23:57:07 mcr