3 Independent submission M. Richardson
5 Expires: November 19, 2003 D. Redelmeier
10 Opportunistic Encryption using The Internet Key Exchange (IKE)
11 draft-richardson-ipsec-opportunistic-11.txt
15 This document is an Internet-Draft and is in full conformance with
16 all provisions of Section 10 of RFC2026.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at http://
29 www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on November 19, 2003.
38 Copyright (C) The Internet Society (2003). All Rights Reserved.
42 This document describes opportunistic encryption (OE) using the
43 Internet Key Exchange (IKE) and IPsec. Each system administrator
44 adds new resource records to his or her Domain Name System (DNS) to
45 support opportunistic encryption. The objective is to allow
46 encryption for secure communication without any pre-arrangement
47 specific to the pair of systems involved.
49 DNS is used to distribute the public keys of each system involved.
50 This is resistant to passive attacks. The use of DNS Security
51 (DNSSEC) secures this system against active attackers as well.
55 Richardson & Redelmeier Expires November 19, 2003 [Page 1]
57 Internet-Draft opportunistic May 2003
60 As a result, the administrative overhead is reduced from the square
61 of the number of systems to a linear dependence, and it becomes
62 possible to make secure communication the default even when the
63 partner is not known in advance.
65 This document is offered up as an Informational RFC.
69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
70 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
71 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 10
72 4. Impacts on IKE . . . . . . . . . . . . . . . . . . . . . . . . 21
73 5. DNS issues . . . . . . . . . . . . . . . . . . . . . . . . . . 24
74 6. Network address translation interaction . . . . . . . . . . . 28
75 7. Host implementations . . . . . . . . . . . . . . . . . . . . . 29
76 8. Multi-homing . . . . . . . . . . . . . . . . . . . . . . . . . 30
77 9. Failure modes . . . . . . . . . . . . . . . . . . . . . . . . 32
78 10. Unresolved issues . . . . . . . . . . . . . . . . . . . . . . 34
79 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
80 12. Security considerations . . . . . . . . . . . . . . . . . . . 42
81 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
82 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
83 Normative references . . . . . . . . . . . . . . . . . . . . . 46
84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47
85 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 48
111 Richardson & Redelmeier Expires November 19, 2003 [Page 2]
113 Internet-Draft opportunistic May 2003
120 The objective of opportunistic encryption is to allow encryption
121 without any pre-arrangement specific to the pair of systems involved.
122 Each system administrator adds public key information to DNS records
123 to support opportunistic encryption and then enables this feature in
124 the nodes' IPsec stack. Once this is done, any two such nodes can
125 communicate securely.
127 This document describes opportunistic encryption as designed and
128 mostly implemented by the Linux FreeS/WAN project. For project
129 information, see http://www.freeswan.org.
131 The Internet Architecture Board (IAB) and Internet Engineering
132 Steering Group (IESG) have taken a strong stand that the Internet
133 should use powerful encryption to provide security and privacy [4].
134 The Linux FreeS/WAN project attempts to provide a practical means to
135 implement this policy.
137 The project uses the IPsec, ISAKMP/IKE, DNS and DNSSEC protocols
138 because they are standardized, widely available and can often be
139 deployed very easily without changing hardware or software or
142 The extensions to support opportunistic encryption are simple. No
143 changes to any on-the-wire formats are needed. The only changes are
144 to the policy decision making system. This means that opportunistic
145 encryption can be implemented with very minimal changes to an
146 existing IPsec implementation.
148 Opportunistic encryption creates a "fax effect". The proliferation
149 of the fax machine was possible because it did not require that
150 everyone buy one overnight. Instead, as each person installed one,
151 the value of having one increased - as there were more people that
152 could receive faxes. Once opportunistic encryption is installed it
153 automatically recognizes other boxes using opportunistic encryption,
154 without any further configuration by the network administrator. So,
155 as opportunistic encryption software is installed on more boxes, its
156 value as a tool increases.
158 This document describes the infrastructure to permit deployment of
159 Opportunistic Encryption.
161 The term S/WAN is a trademark of RSA Data Systems, and is used with
162 permission by this project.
167 Richardson & Redelmeier Expires November 19, 2003 [Page 3]
169 Internet-Draft opportunistic May 2003
172 1.2 Types of network traffic
174 To aid in understanding the relationship between security processing
175 and IPsec we divide network traffic into four categories:
177 * Deny: networks to which traffic is always forbidden.
179 * Permit: networks to which traffic in the clear is permitted.
181 * Opportunistic tunnel: networks to which traffic is encrypted if
182 possible, but otherwise is in the clear or fails depending on the
183 default policy in place.
185 * Configured tunnel: networks to which traffic must be encrypted, and
186 traffic in the clear is never permitted.
188 Traditional firewall devices handle the first two categories. No
189 authentication is required. The permit policy is currently the
190 default on the Internet.
192 This document describes the third category - opportunistic tunnel,
193 which is proposed as the new default for the Internet.
195 Category four, encrypt traffic or drop it, requires authentication of
196 the end points. As the number of end points is typically bounded and
197 is typically under a single authority, arranging for distribution of
198 authentication material, while difficult, does not require any new
199 technology. The mechanism described here provides an additional way
200 to distribute the authentication materials, that of a public key
201 method that does not require deployment of an X.509 based
204 Current Virtual Private Networks can often be replaced by an "OE
205 paranoid" policy as described herein.
207 1.3 Peer authentication in opportunistic encryption
209 Opportunistic encryption creates tunnels between nodes that are
210 essentially strangers. This is done without any prior bilateral
211 arrangement. There is, therefore, the difficult question of how one
212 knows to whom one is talking.
214 One possible answer is that since no useful authentication can be
215 done, none should be tried. This mode of operation is named
216 "anonymous encryption". An active man-in-the-middle attack can be
217 used to thwart the privacy of this type of communication. Without
218 peer authentication, there is no way to prevent this kind of attack.
223 Richardson & Redelmeier Expires November 19, 2003 [Page 4]
225 Internet-Draft opportunistic May 2003
228 Although a useful mode, anonymous encryption is not the goal of this
229 project. Simpler methods are available that can achieve anonymous
230 encryption only, but authentication of the peer is a desireable goal.
231 The latter is achieved through key distribution in DNS, leveraging
232 upon the authentication of the DNS in DNSSEC.
234 Peers are, therefore, authenticated with DNSSEC when available.
235 Local policy determines how much trust to extend when DNSSEC is not
238 However, an essential premise of building private connections with
239 strangers is that datagrams received through opportunistic tunnels
240 are no more special than datagrams that arrive in the clear. Unlike
241 in a VPN, these datagrams should not be given any special exceptions
242 when it comes to auditing, further authentication or firewalling.
244 When initiating outbound opportunistic encryption, local
245 configuration determines what happens if tunnel setup fails. It may
246 be that the packet goes out in the clear, or it may be dropped.
248 1.4 Use of RFC2119 terms
250 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
251 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
252 document, are to be interpreted as described in [5]
279 Richardson & Redelmeier Expires November 19, 2003 [Page 5]
281 Internet-Draft opportunistic May 2003
286 2.1 Reference diagram
288 ---------------------------------------------------------------------
290 The following network diagram is used in the rest of this document as
291 the canonical diagram:
295 [A]----+----[SG-A].......+....+.......[SG-B]-------[B]
299 [D]----+----[SG-D].......+....+.......[C] AS3
303 Figure 1: Reference Network Diagram
305 ---------------------------------------------------------------------
307 In this diagram, there are four end-nodes: A, B, C and D. There are
308 three gateways, SG-A, SG-B, SG-D. A, D, SG-A and SG-D are part of
309 the same administrative authority, AS1. SG-A and SG-D are on two
310 different exit paths from organization 1. SG-B/B is an independent
311 organization, AS2. Nodes Q and R are nodes on the Internet. PI is
312 the Public Internet ("The Wild").
316 The following terminology is used in this document:
318 Security gateway: a system that performs IPsec tunnel mode
319 encapsulation/decapsulation. [SG-x] in the diagram.
321 Alice: node [A] in the diagram. When an IP address is needed, this
324 Bob: node [B] in the diagram. When an IP address is needed, this is
327 Carol: node [C] in the diagram. When an IP address is needed, this
330 Dave: node [D] in the diagram. When an IP address is needed, this is
335 Richardson & Redelmeier Expires November 19, 2003 [Page 6]
337 Internet-Draft opportunistic May 2003
340 SG-A: Alice's security gateway. Internally it is 192.1.0.1,
341 externally it is 192.1.1.4.
343 SG-B: Bob's security gateway. Internally it is 192.2.0.1, externally
346 SG-D: Dave's security gateway. Also Alice's backup security gateway.
347 Internally it is 192.3.0.1, externally it is 192.1.1.6.
349 - A single dash represents clear-text datagrams.
351 = An equals sign represents phase 2 (IPsec) cipher-text datagrams.
353 ~ A single tilde represents clear-text phase 1 datagrams.
355 # A hash sign represents phase 1 (IKE) cipher-text datagrams.
357 . A period represents an untrusted network of unknown type.
359 Configured tunnel: a tunnel that is directly and deliberately hand
360 configured on participating gateways. Configured tunnels are
361 typically given a higher level of trust than opportunistic
364 Road warrior tunnel: a configured tunnel connecting one node with a
365 fixed IP address and one node with a variable IP address. A road
366 warrior (RW) connection must be initiated by the variable node,
367 since the fixed node cannot know the current address for the road
370 Anonymous encryption: the process of encrypting a session without any
371 knowledge of who the other parties are. No authentication of
374 Opportunistic encryption: the process of encrypting a session with
375 authenticated knowledge of who the other parties are.
377 Lifetime: the period in seconds (bytes or datagrams) for which a
378 security association will remain alive before needing to be re-
381 Lifespan: the effective time for which a security association remains
382 useful. A security association with a lifespan shorter than its
383 lifetime would be removed when no longer needed. A security
384 association with a lifespan longer than its lifetime would need to
385 be re-keyed one or more times.
387 Phase 1 SA: an ISAKMP/IKE security association sometimes referred to
391 Richardson & Redelmeier Expires November 19, 2003 [Page 7]
393 Internet-Draft opportunistic May 2003
398 Phase 2 SA: an IPsec security association.
400 Tunnel: another term for a set of phase 2 SA (one in each direction).
402 NAT: Network Address Translation (see [20]).
404 NAPT: Network Address and Port Translation (see [20]).
406 AS: an autonomous system (AS) is a group of systems (a network) that
407 are under the administrative control of a single organization.
409 Default-free zone: a set of routers that maintain a complete set of
410 routes to all currently reachable destinations. Having such a
411 list, these routers never make use of a default route. A datagram
412 with a destination address not matching any route will be dropped
416 2.3 Model of operation
418 The opportunistic encryption security gateway (OE gateway) is a
419 regular gateway node as described in [2] section 2.4 and [3] with the
420 additional capabilities described here and in [7]. The algorithm
421 described here provides a way to determine, for each datagram,
422 whether or not to encrypt and tunnel the datagram. Two important
423 things that must be determined are whether or not to encrypt and
424 tunnel and, if so, the destination address or name of the tunnel end
425 point which should be used.
427 2.3.1 Tunnel authorization
429 The OE gateway determines whether or not to create a tunnel based on
430 the destination address of each packet. Upon receiving a packet with
431 a destination address not recently seen, the OE gateway performs a
432 lookup in DNS for an authorization resource record (see Section 5.2).
433 The record is located using the IP address to perform a search in the
434 in-addr.arpa (IPv4) or ip6.arpa (IPv6) maps. If an authorization
435 record is found, the OE gateway interprets this as a request for a
438 2.3.2 Tunnel end-point discovery
440 The authorization resource record also provides the address or name
441 of the tunnel end point which should be used.
443 The record may also provide the public RSA key of the tunnel end
447 Richardson & Redelmeier Expires November 19, 2003 [Page 8]
449 Internet-Draft opportunistic May 2003
452 point itself. This is provided for efficiency only. If the public
453 RSA key is not present, the OE gateway performs a second lookup to
454 find a KEY resource record for the end point address or name.
456 Origin and integrity protection of the resource records is provided
457 by DNSSEC ([16]). Section 3.2.4.1 documents an optional restriction
458 on the tunnel end point if DNSSEC signatures are not available for
459 the relevant records.
461 2.3.3 Caching of authorization results
463 The OE gateway maintains a cache, in the forwarding plane, of source/
464 destination pairs for which opportunistic encryption has been
465 attempted. This cache maintains a record of whether or not OE was
466 successful so that subsequent datagrams can be forwarded properly
467 without additional delay.
469 Successful negotiation of OE instantiates a new security association.
470 Failure to negotiate OE results in creation of a forwarding policy
471 entry either to drop or transmit in the clear future datagrams. This
472 negative cache is necessary to avoid the possibly lengthy process of
473 repeatedly looking up the same information.
475 The cache is timed out periodically, as described in Section 3.4.
476 This removes entries that are no longer being used and permits the
477 discovery of changes in authorization policy.
503 Richardson & Redelmeier Expires November 19, 2003 [Page 9]
505 Internet-Draft opportunistic May 2003
510 The OE gateway is modeled to have a forwarding plane and a control
511 plane. A control channel, such as PF_KEY, connects the two planes.
512 (See [6].) The forwarding plane performs per datagram operations.
513 The control plane contains a keying daemon, such as ISAKMP/IKE, and
514 performs all authorization, peer authentication and key derivation
517 3.1 Datagram state machine
519 Let the OE gateway maintain a collection of objects -- a superset of
520 the security policy database (SPD) specified in [7]. For each
521 combination of source and destination address, an SPD object exists
522 in one of five following states. Prior to forwarding each datagram,
523 the responder uses the source and destination addresses to pick an
524 entry from the SPD. The SPD then determines if and how the packet is
527 3.1.1 Non-existent policy
529 If the responder does not find an entry, then this policy applies.
530 The responder creates an entry with an initial state of "hold policy"
531 and requests keying material from the keying daemon. The responder
532 does not forward the datagram, rather it attaches the datagram to the
533 SPD entry as the "first" datagram and retains it for eventual
534 transmission in a new state.
538 The responder requests keying material. If the interface to the
539 keying system is lossy (PF_KEY, for instance, can be), the
540 implementation SHOULD include a mechanism to retransmit the keying
541 request at a rate limited to less than 1 request per second. The
542 responder does not forward the datagram. It attaches the datagram to
543 the SPD entry as the "last" datagram where it is retained for
544 eventual transmission. If there is a datagram already so stored,
545 then that already stored datagram is discarded.
547 Because the "first" datagram is probably a TCP SYN packet, the
548 responder retains the "first" datagram in an attempt to avoid waiting
549 for a TCP retransmit. The responder retains the "last" datagram in
550 deference to streaming protocols that find it useful to know how much
551 data has been lost. These are recommendations to decrease latency.
552 There are no operational requirements for this.
559 Richardson & Redelmeier Expires November 19, 2003 [Page 10]
561 Internet-Draft opportunistic May 2003
564 3.1.3 Pass-through policy
566 The responder forwards the datagram using the normal forwarding
567 table. The responder enters this state only by command from the
568 keying daemon, and upon entering this state, also forwards the
569 "first" and "last" datagrams.
573 The responder discards the datagram. The responder enters this state
574 only by command from the keying daemon, and upon entering this state,
575 discards the "first" and "last" datagrams. Local administration
576 decides if further datagrams cause ICMP messages to be generated
577 (i.e. ICMP Destination Unreachable, Communication Administratively
578 Prohibited. type=3, code=13).
582 The responder encrypts the datagram using the indicated security
583 association database (SAD) entry. The responder enters this state
584 only by command from the keying daemon, and upon entering this state,
585 releases and forwards the "first" and "last" datagrams using the new
588 If the associated SAD entry expires because of byte, packet or time
589 limits, then the entry returns to the Hold policy, and an expire
590 message is sent to the keying daemon.
592 All states may be created directly by the keying daemon while acting
595 3.2 Keying state machine - initiator
597 Let the keying daemon maintain a collection of objects. Let them be
598 called "connections" or "conn"s. There are two categories of
599 connection objects: classes and instances. A class represents an
600 abstract policy - what could be. An instance represents an actual
601 connection - what is implemented at the time.
603 Let there be two further subtypes of connections: keying channels
604 (Phase 1 SAs) and data channels (Phase 2 SAs). Each data channel
605 object may have a corresponding SPD and SAD entry maintained by the
606 datagram state machine.
608 For the purposes of opportunistic encryption, there MUST, at least,
609 be connection classes known as "deny", "always-clear-text", "OE-
610 permissive", and "OE-paranoid". The latter two connection classes
611 define a set of source and/or destination addresses for which
615 Richardson & Redelmeier Expires November 19, 2003 [Page 11]
617 Internet-Draft opportunistic May 2003
620 opportunistic encryption will be attempted. The administrator MAY
621 set policy options in a number of additional places. An
622 implementation MAY create additional connection classes to further
623 refine these policies.
625 The simplest system may need only the "OE-permissive" connection, and
626 would list its own (single) IP address as the source address of this
627 policy and the wild-card address 0.0.0.0/0 as the destination IPv4
628 address. That is, the simplest policy is to try opportunistic
629 encryption with all destinations.
631 The distinction between permissive and paranoid OE use will become
632 clear in the state transition differences. In general a permissive
633 OE will, on failure, install a pass-through policy, while a paranoid
634 OE will, on failure, install a drop policy.
636 In this description of the keying machine's state transitions, the
637 states associated with the keying system itself are omitted because
638 they are best documented in the keying system ([8], [9] and [10] for
639 ISAKMP/IKE), and the details are keying system specific.
640 Opportunistic encryption is not dependent upon any specific keying
641 protocol, but this document does provide requirements for those using
642 ISAKMP/IKE to assure that implementations inter-operate.
644 The state transitions that may be involved in communicating with the
645 forwarding plane are omitted. PF_KEY and similar protocols have
646 their own set of states required for message sends and completion
649 Finally, the retransmits and recursive lookups that are normal for
650 DNS are not included in this description of the state machine.
652 3.2.1 Nonexistent connection
654 There is no connection instance for a given source/destination
655 address pair. Upon receipt of a request for keying material for this
656 source/destination pair, the initiator searches through the
657 connection classes to determine the most appropriate policy. Upon
658 determining an appropriate connection class, an instance object is
659 created of that type. Both of the OE types result in a potential OE
662 Failure to find an appropriate connection class results in an
663 administrator defined default.
665 In each case, when the initiator finds an appropriate class for the
666 new flow, an instance connection is made of the class which matched.
671 Richardson & Redelmeier Expires November 19, 2003 [Page 12]
673 Internet-Draft opportunistic May 2003
676 3.2.2 Clear-text connection
678 The non-existent connection makes a transition to this state when an
679 always-clear-text class is instantiated, or when an OE-permissive
680 connection fails. During the transition, the initiator creates a
681 pass-through policy object in the forwarding plane for the
684 Timing out is the only way to leave this state (see Section 3.2.7).
686 3.2.3 Deny connection
688 The empty connection makes a transition to this state when a deny
689 class is instantiated, or when an OE-paranoid connection fails.
690 During the transition, the initiator creates a deny policy object in
691 the forwarding plane for the appropriate flow.
693 Timing out is the only way to leave this state (see Section 3.2.7).
695 3.2.4 Potential OE connection
697 The empty connection makes a transition to this state when one of
698 either OE class is instantiated. During the transition to this
699 state, the initiator creates a hold policy object in the forwarding
700 plane for the appropriate flow.
702 In addition, when making a transition into this state, DNS lookup is
703 done in the reverse-map for a TXT delegation resource record (see
704 Section 5.2). The lookup key is the destination address of the flow.
706 There are three ways to exit this state:
708 1. DNS lookup finds a TXT delegation resource record.
710 2. DNS lookup does not find a TXT delegation resource record.
712 3. DNS lookup times out.
714 Based upon the results of the DNS lookup, the potential OE connection
715 makes a transition to the pending OE connection state. The
716 conditions for a successful DNS look are:
718 1. DNS finds an appropriate resource record
720 2. It is properly formatted according to Section 5.2
722 3. if DNSSEC is enabled, then the signature has been vouched for.
727 Richardson & Redelmeier Expires November 19, 2003 [Page 13]
729 Internet-Draft opportunistic May 2003
732 Note that if the initiator does not find the public key present in
733 the TXT delegation record, then the public key must be looked up as a
734 sub-state. Only successful completion of all the DNS lookups is
735 considered a success.
737 If DNS lookup does not find a resource record or DNS times out, then
738 the initiator considers the receiver not OE capable. If this is an
739 OE-paranoid instance, then the potential OE connection makes a
740 transition to the deny connection state. If this is an OE-permissive
741 instance, then the potential OE connection makes a transition to the
742 clear-text connection state.
744 If the initiator finds a resource record but it is not properly
745 formatted, or if DNSSEC is enabled and reports a failure to
746 authenticate, then the potential OE connection should make a
747 transition to the deny connection state. This action SHOULD be
748 logged. If the administrator wishes to override this transition
749 between states, then an always-clear class can be installed for this
750 flow. An implementation MAY make this situation a new class.
752 3.2.4.1 Restriction on unauthenticated TXT delegation records
754 An implementation SHOULD also provide an additional administrative
755 control on delegation records and DNSSEC. This control would apply
756 to delegation records (the TXT records in the reverse-map) that are
757 not protected by DNSSEC. Records of this type are only permitted to
758 delegate to their own address as a gateway. When this option is
759 enabled, an active attack on DNS will be unable to redirect packets
760 to other than the original destination.
762 3.2.5 Pending OE connection
764 The potential OE connection makes a transition to this state when the
765 initiator determines that all the information required from the DNS
766 lookup is present. Upon entering this state, the initiator attempts
767 to initiate keying to the gateway provided.
769 Exit from this state occurs either with a successfully created IPsec
770 SA, or with a failure of some kind. Successful SA creation results
771 in a transition to the key connection state.
773 Three failures have caused significant problems. They are clearly
774 not the only possible failures from keying.
776 Note that if there are multiple gateways available in the TXT
777 delegation records, then a failure can only be declared after all
778 have been tried. Further, creation of a phase 1 SA does not
779 constitute success. A set of phase 2 SAs (a tunnel) is considered
783 Richardson & Redelmeier Expires November 19, 2003 [Page 14]
785 Internet-Draft opportunistic May 2003
790 The first failure occurs when an ICMP port unreachable is
791 consistently received without any other communication, or when there
792 is silence from the remote end. This usually means that either the
793 gateway is not alive, or the keying daemon is not functional. For an
794 OE-permissive connection, the initiator makes a transition to the
795 clear-text connection but with a low lifespan. For an OE-pessimistic
796 connection, the initiator makes a transition to the deny connection
797 again with a low lifespan. The lifespan in both cases is kept low
798 because the remote gateway may be in the process of rebooting or be
799 otherwise temporarily unavailable.
801 The length of time to wait for the remote keying daemon to wake up is
802 a matter of some debate. If there is a routing failure, 5 minutes is
803 usually long enough for the network to re-converge. Many systems can
804 reboot in that amount of time as well. However, 5 minutes is far too
805 long for most users to wait to hear that they can not connect using
806 OE. Implementations SHOULD make this a tunable parameter.
808 The second failure occurs after a phase 1 SA has been created, but
809 there is either no response to the phase 2 proposal, or the initiator
810 receives a negative notify (the notify must be authenticated). The
811 remote gateway is not prepared to do OE at this time. As before, the
812 initiator makes a transition to the clear-text or the deny connection
813 based upon connection class, but this time with a normal lifespan.
815 The third failure occurs when there is signature failure while
816 authenticating the remote gateway. This can occur when there has
817 been a key roll-over, but DNS has not caught up. In this case again,
818 the initiator makes a transition to the clear-text or the deny
819 connection based upon the connection class. However, the lifespan
820 depends upon the remaining time to live in the DNS. (Note that
821 DNSSEC signed resource records have a different expiry time than non-
824 3.2.6 Keyed connection
826 The pending OE connection makes a transition to this state when
827 session keying material (the phase 2 SAs) is derived. The initiator
828 creates an encrypt policy in the forwarding plane for this flow.
830 There are three ways to exit this state. The first is by receipt of
831 an authenticated delete message (via the keying channel) from the
832 peer. This is normal teardown and results in a transition to the
833 expired connection state.
835 The second exit is by expiry of the forwarding plane keying material.
839 Richardson & Redelmeier Expires November 19, 2003 [Page 15]
841 Internet-Draft opportunistic May 2003
844 This starts a re-key operation with a transition back to pending OE
845 connection. In general, the soft expiry occurs with sufficient time
846 left to continue to use the keys. A re-key can fail, which may
847 result in the connection failing to clear-text or deny as
848 appropriate. In the event of a failure, the forwarding plane policy
849 does not change until the phase 2 SA (IPsec SA) reaches its hard
852 The third exit is in response to a negotiation from a remote gateway.
853 If the forwarding plane signals the control plane that it has
854 received an unknown SPI from the remote gateway, or an ICMP is
855 received from the remote gateway indicating an unknown SPI, the
856 initiator should consider that the remote gateway has rebooted or
857 restarted. Since these indications are easily forged, the
858 implementation must exercise care. The initiator should make a
859 cautious (rate-limited) attempt to re-key the connection.
861 3.2.7 Expiring connection
863 The initiator will periodically place each of the deny, clear-text,
864 and keyed connections into this sub-state. See Section 3.4 for more
865 details of how often this occurs. The initiator queries the
866 forwarding plane for last use time of the appropriate policy. If the
867 last use time is relatively recent, then the connection returns to
868 the previous deny, clear-text or keyed connection state. If not,
869 then the connection enters the expired connection state.
871 The DNS query and answer that lead to the expiring connection state
872 are also examined. The DNS query may become stale. (A negative,
873 i.e. no such record, answer is valid for the period of time given by
874 the MINIMUM field in an attached SOA record. See [12] section
875 4.3.4.) If the DNS query is stale, then a new query is made. If the
876 results change, then the connection makes a transition to a new state
877 as described in potential OE connection state.
879 Note that when considering how stale a connection is, both outgoing
880 SPD and incoming SAD must be queried as some flows may be
881 unidirectional for some time.
883 Also note that the policy at the forwarding plane is not updated
884 unless there is a conclusion that there should be a change.
886 3.2.8 Expired connection
888 Entry to this state occurs when no datagrams have been forwarded
889 recently via the appropriate SPD and SAD objects. The objects in the
890 forwarding plane are removed (logging any final byte and packet
891 counts if appropriate) and the connection instance in the keying
895 Richardson & Redelmeier Expires November 19, 2003 [Page 16]
897 Internet-Draft opportunistic May 2003
902 The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs
903 as described in Section 3.4.
905 Whether or not to delete the phase 1 SAs at this time is left as a
906 local implementation issue. Implementations that do delete the phase
907 1 SAs MUST send authenticated delete messages to indicate that they
908 are doing so. There is an advantage to keeping the phase 1 SAs until
909 they expire - they may prove useful again in the near future.
911 3.3 Keying state machine - responder
913 The responder has a set of objects identical to those of the
916 The responder receives an invitation to create a keying channel from
919 3.3.1 Unauthenticated OE peer
921 Upon entering this state, the responder starts a DNS lookup for a KEY
922 record for the initiator. The responder looks in the reverse-map for
923 a KEY record for the initiator if the initiator has offered an
924 ID_IPV4_ADDR, and in the forward map if the initiator has offered an
925 ID_FQDN type. (See [8] section 4.6.2.1.)
927 The responder exits this state upon successful receipt of a KEY from
928 DNS, and use of the key to verify the signature of the initiator.
930 Successful authentication of the peer results in a transition to the
931 authenticated OE Peer state.
933 Note that the unauthenticated OE peer state generally occurs in the
934 middle of the key negotiation protocol. It is really a form of
937 3.3.2 Authenticated OE Peer
939 The peer will eventually propose one or more phase 2 SAs. The
940 responder uses the source and destination address in the proposal to
941 finish instantiating the connection state using the connection class
942 table. The responder MUST search for an identical connection object
945 If an identical connection is found, then the responder deletes the
946 old instance, and the new object makes a transition to the pending OE
947 connection state. This means that new ISAKMP connections with a
951 Richardson & Redelmeier Expires November 19, 2003 [Page 17]
953 Internet-Draft opportunistic May 2003
956 given peer will always use the latest instance, which is the correct
957 one if the peer has rebooted in the interim.
959 If an identical connection is not found, then the responder makes the
960 transition according to the rules given for the initiator.
962 Note that if the initiator is in OE-paranoid mode and the responder
963 is in either always-clear-text or deny, then no communication is
964 possible according to policy. An implementation is permitted to
965 create new types of policies such as "accept OE but do not initiate
966 it". This is a local matter.
968 3.4 Renewal and teardown
972 A potentially unlimited number of tunnels may exist. In practice,
973 only a few tunnels are used during a period of time. Unused tunnels
974 MUST, therefore, be torn down. Detecting when tunnels are no longer
975 in use is the subject of this section.
977 There are two methods for removing tunnels: explicit deletion or
980 Explicit deletion requires an IKE delete message. As the deletes
981 MUST be authenticated, both ends of the tunnel must maintain the key
982 channel (phase 1 ISAKMP SA). An implementation which refuses to
983 either maintain or recreate the keying channel SA will be unable to
986 The tunnel expiry method, simply allows the IKE daemon to expire
987 normally without attempting to re-key it.
989 Regardless of which method is used to remove tunnels, the
990 implementation requires a method to determine if the tunnel is still
991 in use. The specifics are a local matter, but the FreeS/WAN project
992 uses the following criteria. These criteria are currently
993 implemented in the key management daemon, but could also be
994 implemented at the SPD layer using an idle timer.
996 Set a short initial (soft) lifespan of 1 minute since many net flows
997 last only a few seconds.
999 At the end of the lifespan, check to see if the tunnel was used by
1000 traffic in either direction during the last 30 seconds. If so,
1001 assign a longer tentative lifespan of 20 minutes after which, look
1002 again. If the tunnel is not in use, then close the tunnel.
1007 Richardson & Redelmeier Expires November 19, 2003 [Page 18]
1009 Internet-Draft opportunistic May 2003
1012 The expiring state in the key management system (see Section 3.2.7)
1013 implements these timeouts. The timer above may be in the forwarding
1014 plane, but then it must be re-settable.
1016 The tentative lifespan is independent of re-keying; it is just the
1017 time when the tunnel's future is next considered. (The term lifespan
1018 is used here rather than lifetime for this reason.) Unlike re-keying,
1019 this tunnel use check is not costly and should happen reasonably
1022 A multi-step back-off algorithm is not considered worth the effort
1025 If the security gateway and the client host are the same and not a
1026 Bump-in-the-Stack or Bump-in-the-Wire implementation, tunnel teardown
1027 decisions MAY pay attention to TCP connection status as reported by
1028 the local TCP layer. A still-open TCP connection is almost a
1029 guarantee that more traffic is expected. Closing of the only TCP
1030 connection through a tunnel is a strong hint that no more traffic is
1033 3.4.2 Teardown and cleanup
1035 Teardown should always be coordinated between the two ends of the
1036 tunnel by interpreting and sending delete notifications. There is a
1037 detailed sub-state in the expired connection state of the key manager
1038 that relates to retransmits of the delete notifications, but this is
1039 considered to be a keying system detail.
1041 On receiving a delete for the outbound SAs of a tunnel (or some
1042 subset of them), tear down the inbound ones also and notify the
1043 remote end with a delete. If the local system receives a delete for
1044 a tunnel which is no longer in existence, then two delete messages
1045 have crossed paths. Ignore the delete. The operation has already
1046 been completed. Do not generate any messages in this situation.
1048 Tunnels are to be considered as bidirectional entities, even though
1049 the low-level protocols don't treat them this way.
1051 When the deletion is initiated locally, rather than as a response to
1052 a received delete, send a delete for (all) the inbound SAs of a
1053 tunnel. If the local system does not receive a responding delete for
1054 the outbound SAs, try re-sending the original delete. Three tries
1055 spaced 10 seconds apart seems a reasonable level of effort. A
1056 failure of the other end to respond after 3 attempts, indicates that
1057 the possibility of further communication is unlikely. Remove the
1058 outgoing SAs. (The remote system may be a mobile node that is no
1059 longer present or powered on.)
1063 Richardson & Redelmeier Expires November 19, 2003 [Page 19]
1065 Internet-Draft opportunistic May 2003
1068 After re-keying, transmission should switch to using the new outgoing
1069 SAs (ISAKMP or IPsec) immediately, and the old leftover outgoing SAs
1070 should be cleared out promptly (delete should be sent for the
1071 outgoing SAs) rather than waiting for them to expire. This reduces
1072 clutter and minimizes confusion for the operator doing diagnostics.
1119 Richardson & Redelmeier Expires November 19, 2003 [Page 20]
1121 Internet-Draft opportunistic May 2003
1126 4.1 ISAKMP/IKE protocol
1128 The IKE wire protocol needs no modifications. The major changes are
1129 implementation issues relating to how the proposals are interpreted,
1130 and from whom they may come.
1132 As opportunistic encryption is designed to be useful between peers
1133 without prior operator configuration, an IKE daemon must be prepared
1134 to negotiate phase 1 SAs with any node. This may require a large
1135 amount of resources to maintain cookie state, as well as large
1136 amounts of entropy for nonces, cookies and so on.
1138 The major changes to support opportunistic encryption are at the IKE
1139 daemon level. These changes relate to handling of key acquisition
1140 requests, lookup of public keys and TXT records, and interactions
1141 with firewalls and other security facilities that may be co-resident
1142 on the same gateway.
1144 4.2 Gateway discovery process
1146 In a typical configured tunnel, the address of SG-B is provided via
1147 configuration. Furthermore, the mapping of an SPD entry to a gateway
1148 is typically a 1:1 mapping. When the 0.0.0.0/0 SPD entry technique
1149 is used, then the mapping to a gateway is determined by the reverse
1152 The need to do a DNS lookup and wait for a reply will typically
1153 introduce a new state and a new event source (DNS replies) to IKE.
1154 Although a synchronous DNS request can be implemented for proof of
1155 concept, experience is that it can cause very high latencies when a
1156 queue of queries must all timeout in series.
1158 Use of an asynchronous DNS lookup will also permit overlap of DNS
1159 lookups with some of the protocol steps.
1161 4.3 Self identification
1163 SG-A will have to establish its identity. Use an IPv4 ID in phase 1.
1165 There are many situations where the administrator of SG-A may not be
1166 able to control the reverse DNS records for SG-A's public IP address.
1167 Typical situations include dialup connections and most residential-
1168 type broadband Internet access (ADSL, cable-modem) connections. In
1169 these situations, a fully qualified domain name that is under the
1170 control of SG-A's administrator may be used when acting as an
1171 initiator only. The FQDN ID should be used in phase 1. See Section
1175 Richardson & Redelmeier Expires November 19, 2003 [Page 21]
1177 Internet-Draft opportunistic May 2003
1180 5.3 for more details and restrictions.
1182 4.4 Public key retrieval process
1184 Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID
1185 or an FQDN ID, an IKE daemon needs to examine local caches and
1186 configuration files to determine if this is part of a configured
1187 tunnel. If no configured tunnels are found, then the implementation
1188 should attempt to retrieve a KEY record from the reverse DNS in the
1189 case of an IPv4/IPv6 ID, or from the forward DNS in the case of FQDN
1192 It is reasonable that if other non-local sources of policy are used
1193 (COPS, LDAP), they be consulted concurrently but some clear ordering
1194 of policy be provided. Note that due to variances in latency,
1195 implementations must wait for positive or negative replies from all
1196 sources of policy before making any decisions.
1198 4.5 Interactions with DNSSEC
1200 The implementation described (1.98) neither uses DNSSEC directly to
1201 explicitly verify the authenticity of zone information, nor uses the
1202 NXT records to provide authentication of the absence of a TXT or KEY
1203 record. Rather, this implementation uses a trusted path to a DNSSEC
1204 capable caching resolver.
1206 To distinguish between an authenticated and an unauthenticated DNS
1207 resource record, a stub resolver capable of returning DNSSEC
1208 information MUST be used.
1210 4.6 Required proposal types
1212 4.6.1 Phase 1 parameters
1214 Main mode MUST be used.
1216 The initiator MUST offer at least one proposal using some combination
1217 of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be
1218 proposed first. [11]
1220 The initiator MAY offer additional proposals, but the cipher MUST not
1221 be weaker than 3DES. The initiator SHOULD limit the number of
1222 proposals such that the IKE datagrams do not need to be fragmented.
1224 The responder MUST accept one of the proposals. If any configuration
1225 of the responder is required then the responder is not acting in an
1231 Richardson & Redelmeier Expires November 19, 2003 [Page 22]
1233 Internet-Draft opportunistic May 2003
1236 SG-A SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6) of the
1237 external interface of SG-A for phase 1. (There is an exception, see
1238 Section 5.3.) The authentication method MUST be RSA public key
1239 signatures. The RSA key for SG-A SHOULD be placed into a DNS KEY
1240 record in the reverse space of SG-A (i.e. using in-addr.arpa).
1242 4.6.2 Phase 2 parameters
1244 SG-A MUST propose a tunnel between Alice and Bob, using 3DES-CBC
1245 mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be
1248 Tunnel mode MUST be used.
1250 Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32.
1252 Authorization for SG-A to act on Alice's behalf is determined by
1253 looking for a TXT record in the reverse-map at Alice's address.
1255 Compression SHOULD NOT be mandatory. It may be offered as an option.
1287 Richardson & Redelmeier Expires November 19, 2003 [Page 23]
1289 Internet-Draft opportunistic May 2003
1294 5.1 Use of KEY record
1296 In order to establish their own identities, SG-A and SG-B SHOULD
1297 publish their public keys in their reverse DNS via DNSSEC's KEY
1298 record. See section 3 of RFC 2535 [16].
1302 KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
1304 0x4200: The flag bits, indicating that this key is prohibited for
1305 confidentiality use (it authenticates the peer only, a separate
1306 Diffie-Hellman exchange is used for confidentiality), and that
1307 this key is associated with the non-zone entity whose name is the
1308 RR owner name. No other flags are set.
1310 4: This indicates that this key is for use by IPsec.
1312 1: An RSA key is present.
1314 AQNJjkKlIk9...nYyUkKK8: The public key of the host as described in
1317 Use of several KEY records allows for key rollover. The SIG Payload
1318 in IKE phase 1 SHOULD be accepted if the public key given by any KEY
1321 5.2 Use of TXT delegation record
1323 Alice publishes a TXT record to provide authorization for SG-A to act
1324 on Alice's behalf. Bob publishes a TXT record to provide
1325 authorization for SG-B to act on Bob's behalf. These records are
1326 located in the reverse DNS (in-addr.arpa) for their respective IP
1327 addresses. The reverse DNS SHOULD be secured by DNSSEC, when it is
1328 deployed. DNSSEC is required to defend against active attacks.
1330 If Alice's address is P.Q.R.S, then she can authorize another node to
1331 act on her behalf by publishing records at:
1333 S.R.Q.P.in-addr.arpa
1335 The contents of the resource record are expected to be a string that
1336 uses the following syntax, as suggested in [15]. (Note that the
1337 reply to query may include other TXT resource records used by other
1343 Richardson & Redelmeier Expires November 19, 2003 [Page 24]
1345 Internet-Draft opportunistic May 2003
1348 ---------------------------------------------------------------------
1351 X-IPsec-Server(P)=A.B.C.D KEY
1353 Figure 2: Format of reverse delegation record
1355 ---------------------------------------------------------------------
1357 P: Specifies a precedence for this record. This is similar to MX
1358 record preferences. Lower numbers have stronger preference.
1360 A.B.C.D: Specifies the IP address of the Security Gateway for this
1363 KEY: Is the encoded RSA Public key of the Security Gateway. The key
1364 is provided here to avoid a second DNS lookup. If this field is
1365 absent, then a KEY resource record should be looked up in the
1366 reverse-map of A.B.C.D. The key is transmitted in base64 format.
1368 The pieces of the record are separated by any whitespace (space, tab,
1369 newline, carriage return). An ASCII space SHOULD be used.
1371 In the case where Alice is located at a public address behind a
1372 security gateway that has no fixed address (or no control over its
1373 reverse-map), then Alice may delegate to a public key by domain name.
1375 ---------------------------------------------------------------------
1378 X-IPsec-Server(P)=@FQDN KEY
1380 Figure 3: Format of reverse delegation record (FQDN version)
1382 ---------------------------------------------------------------------
1386 FQDN: Specifies the FQDN that the Security Gateway will identify
1389 KEY: Is the encoded RSA Public key of the Security Gateway.
1391 If there is more than one such TXT record with strongest (lowest
1392 numbered) precedence, one Security Gateway is picked arbitrarily from
1393 those specified in the strongest-preference records.
1399 Richardson & Redelmeier Expires November 19, 2003 [Page 25]
1401 Internet-Draft opportunistic May 2003
1404 5.2.1 Long TXT records
1406 When packed into transport format, TXT records which are longer than
1407 255 characters are divided into smaller <character-strings>. (See
1408 [13] section 3.3 and 3.3.14.) These MUST be reassembled into a single
1409 string for processing. Whitespace characters in the base64 encoding
1412 5.2.2 Choice of TXT record
1414 It has been suggested to use the KEY, OPT, CERT, or KX records
1415 instead of a TXT record. None is satisfactory.
1417 The KEY RR has a protocol field which could be used to indicate a new
1418 protocol, and an algorithm field which could be used to indicate
1419 different contents in the key data. However, the KEY record is
1420 clearly not intended for storing what are really authorizations, it
1421 is just for identities. Other uses have been discouraged.
1423 OPT resource records, as defined in [14] are not intended to be used
1424 for storage of information. They are not to be loaded, cached or
1425 forwarded. They are, therefore, inappropriate for use here.
1427 CERT records [18] can encode almost any set of information. A custom
1428 type code could be used permitting any suitable encoding to be
1429 stored, not just X.509. According to the RFC, the certificate RRs
1430 are to be signed internally which may add undesirable and unnecessary
1431 bulk. Larger DNS records may require TCP instead of UDP transfers.
1433 At the time of protocol design, the CERT RR was not widely deployed
1434 and could not be counted upon. Use of CERT records will be
1435 investigated, and may be proposed in a future revision of this
1438 KX records are ideally suited for use instead of TXT records, but had
1439 not been deployed at the time of implementation.
1443 Unfortunately, not every administrator has control over the contents
1444 of the reverse-map. Where the initiator (SG-A) has no suitable
1445 reverse-map, the authorization record present in the reverse-map of
1446 Alice may refer to a FQDN instead of an IP address.
1448 In this case, the client's TXT record gives the fully qualified
1449 domain name (FQDN) in place of its security gateway's IP address.
1450 The initiator should use the ID_FQDN ID-payload in phase 1. A
1451 forward lookup for a KEY record on the FQDN must yield the
1455 Richardson & Redelmeier Expires November 19, 2003 [Page 26]
1457 Internet-Draft opportunistic May 2003
1460 initiator's public key.
1462 This method can also be used when the external address of SG-A is
1465 If SG-A is acting on behalf of Alice, then Alice must still delegate
1466 authority for SG-A to do so in her reverse-map. When Alice and SG-A
1467 are one and the same (i.e. Alice is acting as an end-node) then
1468 there is no need for this when initiating only.
1470 However, Alice must still delegate to herself if she wishes others
1471 to initiate OE to her. See Figure 3.
1475 Good cryptographic hygiene says that one should replace public/
1476 private key pairs periodically. Some administrators may wish to do
1477 this as often as daily. Typical DNS propagation delays are
1478 determined by the SOA Resource Record MINIMUM parameter, which
1479 controls how long DNS replies may be cached. For reasonable
1480 operation of DNS servers, administrators usually want this value to
1481 be at least several hours, sometimes as a long as a day. This
1482 presents a problem - a new key MUST not be used prior to it
1483 propagating through DNS.
1485 This problem is dealt with by having the Security Gateway generate a
1486 new public/private key pair at least MINIMUM seconds in advance of
1487 using it. It then adds this key to the DNS (both as a second KEY
1488 record and in additional TXT delegation records) at key generation
1489 time. Note: only one key is allowed in each TXT record.
1491 When authenticating, all gateways MUST have available all public keys
1492 that are found in DNS for this entity. This permits the
1493 authenticating end to check both the key for "today" and the key for
1494 "tomorrow". Note that it is the end which is creating the signature
1495 (possesses the private key) that determines which key is to be used.
1511 Richardson & Redelmeier Expires November 19, 2003 [Page 27]
1513 Internet-Draft opportunistic May 2003
1516 6. Network address translation interaction
1518 There are no fundamentally new issues for implementing opportunistic
1519 encryption in the presence of network address translation. Rather
1520 there are only the regular IPsec issues with NAT traversal.
1522 There are several situations to consider for NAT.
1524 6.1 Co-located NAT/NAPT
1526 If SG-A is also performing network address translation on behalf of
1527 Alice, then the packet should be translated prior to being subjected
1528 to opportunistic encryption. This is in contrast to typically
1529 configured tunnels which often exist to bridge islands of private
1530 network address space. SG-A will use the translated source address
1531 for phase 2, and so SG-B will look up that address to confirm SG-A's
1534 In the case of NAT (1:1), the address space into which the
1535 translation is done MUST be globally unique, and control over the
1536 reverse-map is assumed. Placing of TXT records is possible.
1538 In the case of NAPT (m:1), the address will be SG-A. The ability to
1539 get KEY and TXT records in place will again depend upon whether or
1540 not there is administrative control over the reverse-map. This is
1541 identical to situations involving a single host acting on behalf of
1542 itself. FQDN style can be used to get around a lack of a reverse-map
1543 for initiators only.
1545 6.2 SG-A behind NAT/NAPT
1547 If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec
1548 NAT traversal rules apply. In addition to the transport problem
1549 which may be solved by other mechanisms, there is the issue of what
1550 phase 1 and phase 2 IDs to use. While FQDN could be used during
1551 phase 1 for SG-A, there is no appropriate ID for phase 2 that permits
1552 SG-B to determine that SG-A is in fact authorized to speak for Alice.
1554 6.3 Bob is behind a NAT/NAPT
1556 If Bob is behind a NAT (perhaps SG-B), then there is, in fact, no way
1557 for Alice to address a packet to Bob. Not only is opportunistic
1558 encryption impossible, but it is also impossible for Alice to
1559 initiate any communication to Bob. It may be possible for Bob to
1560 initiate in such a situation. This creates an asymmetry, but this is
1567 Richardson & Redelmeier Expires November 19, 2003 [Page 28]
1569 Internet-Draft opportunistic May 2003
1572 7. Host implementations
1574 When Alice and SG-A are components of the same system, they are
1575 considered to be a host implementation. The packet sequence scenario
1578 Components marked Alice are the upper layers (TCP, UDP, the
1579 application), and SG-A is the IP layer.
1581 Note that tunnel mode is still required.
1583 As Alice and SG-A are acting on behalf of themselves, no TXT based
1584 delegation record is necessary for Alice to initiate. She can rely
1585 on FQDN in a forward map. This is particularly attractive to mobile
1586 nodes such as notebook computers at conferences. To respond, Alice/
1587 SG-A will still need an entry in Alice's reverse-map.
1623 Richardson & Redelmeier Expires November 19, 2003 [Page 29]
1625 Internet-Draft opportunistic May 2003
1630 If there are multiple paths between Alice and Bob (as illustrated in
1631 the diagram with SG-D), then additional DNS records are required to
1632 establish authorization.
1634 In Figure 1, Alice has two ways to exit her network: SG-A and SG-D.
1635 Previously SG-D has been ignored. Postulate that there are routers
1636 between Alice and her set of security gateways (denoted by the +
1637 signs and the marking of an autonomous system number for Alice's
1638 network). Datagrams may, therefore, travel to either SG-A or SG-D en
1641 As long as all network connections are in good order, it does not
1642 matter how datagrams exit Alice's network. When they reach either
1643 security gateway, the security gateway will find the TXT delegation
1644 record in Bob's reverse-map, and establish an SA with SG-B.
1646 SG-B has no problem establishing that either of SG-A or SG-D may
1647 speak for Alice, because Alice has published two equally weighted TXT
1650 ---------------------------------------------------------------------
1653 X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
1654 X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
1656 Figure 4: Multiple gateway delegation example for Alice
1658 ---------------------------------------------------------------------
1660 Alice's routers can now do any kind of load sharing needed. Both SG-
1661 A and SG-D send datagrams addressed to Bob through their tunnel to
1664 Alice's use of non-equal weight delegation records to show preference
1665 of one gateway over another, has relevance only when SG-B is
1666 initiating to Alice.
1668 If the precedences are the same, then SG-B has a more difficult time.
1669 It must decide which of the two tunnels to use. SG-B has no
1670 information about which link is less loaded, nor which security
1671 gateway has more cryptographic resources available. SG-B, in fact,
1672 has no knowledge of whether both gateways are even reachable.
1674 The Public Internet's default-free zone may well know a good route to
1675 Alice, but the datagrams that SG-B creates must be addressed to
1679 Richardson & Redelmeier Expires November 19, 2003 [Page 30]
1681 Internet-Draft opportunistic May 2003
1684 either SG-A or SG-D; they can not be addressed to Alice directly.
1686 SG-B may make a number of choices:
1688 1. It can ignore the problem and round robin among the tunnels.
1689 This causes losses during times when one or the other security
1690 gateway is unreachable. If this worries Alice, she can change
1691 the weights in her TXT delegation records.
1693 2. It can send to the gateway from which it most recently received
1694 datagrams. This assumes that routing and reachability are
1697 3. It can listen to BGP information from the Internet to decide
1698 which system is currently up. This is clearly much more
1699 complicated, but if SG-B is already participating in the BGP
1700 peering system to announce Bob, the results data may already be
1703 4. It can refuse to negotiate the second tunnel. (It is unclear
1704 whether or not this is even an option.)
1706 5. It can silently replace the outgoing portion of the first tunnel
1707 with the second one while still retaining the incoming portions
1708 of both. SG-B can, thus, accept datagrams from either SG-A or
1709 SG-D, but send only to the gateway that most recently re-keyed
1712 Local policy determines which choice SG-B makes. Note that even if
1713 SG-B has perfect knowledge about the reachability of SG-A and SG-D,
1714 Alice may not be reachable from either of these security gateways
1715 because of internal reachability issues.
1717 FreeS/WAN implements option 5. Implementing a different option is
1718 being considered. The multi-homing aspects of OE are not well
1719 developed and may be the subject of a future document.
1735 Richardson & Redelmeier Expires November 19, 2003 [Page 31]
1737 Internet-Draft opportunistic May 2003
1744 If a DNS server fails to respond, local policy decides whether or not
1745 to permit communication in the clear as embodied in the connection
1746 classes in Section 3.2. It is easy to mount a denial of service
1747 attack on the DNS server responsible for a particular network's
1748 reverse-map. Such an attack may cause all communication with that
1749 network to go in the clear if the policy is permissive, or fail
1750 completely if the policy is paranoid. Please note that this is an
1753 There are still many networks that do not have properly configured
1754 reverse-maps. Further, if the policy is not to communicate, the
1755 above denial of service attack isolates the target network.
1756 Therefore, the decision of whether or not to permit communication in
1757 the clear MUST be a matter of local policy.
1759 9.2 DNS configured, IKE failures
1761 DNS records claim that opportunistic encryption should occur, but the
1762 target gateway either does not respond on port 500, or refuses the
1763 proposal. This may be because of a crash or reboot, a faulty
1764 configuration, or a firewall filtering port 500.
1766 The receipt of ICMP port, host or network unreachable messages
1767 indicates a potential problem, but MUST NOT cause communication to
1768 fail immediately. ICMP messages are easily forged by attackers. If
1769 such a forgery caused immediate failure, then an active attacker
1770 could easily prevent any encryption from ever occurring, possibly
1771 preventing all communication.
1773 In these situations a clear log should be produced and local policy
1774 should dictate if communication is then permitted in the clear.
1778 Tunnels sometimes go down because the remote end crashes,
1779 disconnects, or has a network link break. In general there is no
1780 notification of this. Even in the event of a crash and successful
1781 reboot, other SGs don't hear about it unless the rebooted SG has
1782 specific reason to talk to them immediately. Over-quick response to
1783 temporary network outages is undesirable. Note that a tunnel can be
1784 torn down and then re-established without any effect visible to the
1785 user except a pause in traffic. On the other hand, if one end
1786 reboots, the other end can't get datagrams to it at all (except via
1787 IKE) until the situation is noticed. So a bias toward quick response
1791 Richardson & Redelmeier Expires November 19, 2003 [Page 32]
1793 Internet-Draft opportunistic May 2003
1796 is appropriate even at the cost of occasional false alarms.
1798 A mechanism for recovery after reboot is a topic of current research
1799 and is not specified in this document.
1801 A deliberate shutdown should include an attempt, using deletes, to
1802 notify all other SGs currently connected by phase 1 SAs that
1803 communication is about to fail. Again, a remote SG will assume this
1804 is a teardown. Attempts by the remote SGs to negotiate new tunnels
1805 as replacements should be ignored. When possible, SGs should attempt
1806 to preserve information about currently-connected SGs in non-volatile
1807 storage, so that after a crash, an Initial-Contact can be sent to
1808 previous partners to indicate loss of all previously established
1847 Richardson & Redelmeier Expires November 19, 2003 [Page 33]
1849 Internet-Draft opportunistic May 2003
1852 10. Unresolved issues
1854 10.1 Control of reverse DNS
1856 The method of obtaining information by reverse DNS lookup causes
1857 problems for people who cannot control their reverse DNS bindings.
1858 This is an unresolved problem in this version, and is out of scope.
1903 Richardson & Redelmeier Expires November 19, 2003 [Page 34]
1905 Internet-Draft opportunistic May 2003
1910 11.1 Clear-text usage (permit policy)
1912 Two example scenarios follow. In the first example GW-A (Gateway A)
1913 and GW-B (Gateway B) have always-clear-text policies, and in the
1914 second example they have an OE policy.
1916 ---------------------------------------------------------------------
1919 Alice SG-A DNS SG-B Bob
1921 ------(2)-------------->
1922 <-----(3)---------------
1924 ----------(6)------>
1927 <----------(9)------
1930 ----------(12)----->
1933 <-------------------
1936 Figure 5: Timing of regular transaction
1938 ---------------------------------------------------------------------
1940 Alice wants to communicate with Bob. Perhaps she wants to retrieve a
1941 web page from Bob's web server. In the absence of opportunistic
1942 encryptors, the following events occur:
1944 (1) Human or application 'clicks' with a name.
1946 (2) Application looks up name in DNS to get IP address.
1948 (3) Resolver returns A record to application.
1950 (4) Application starts a TCP session or UDP session and OS sends
1953 (5) Datagram is seen at first gateway from Alice (SG-A). (SG-A makes
1954 a transition through Empty connection to always-clear connection
1955 and instantiates a pass-through policy at the forwarding plane.)
1959 Richardson & Redelmeier Expires November 19, 2003 [Page 35]
1961 Internet-Draft opportunistic May 2003
1964 (6) Datagram is seen at last gateway before Bob (SG-B).
1966 (7) First datagram from Alice is seen by Bob.
1968 (8) First return datagram is sent by Bob.
1970 (9) Datagram is seen at Bob's gateway. (SG-B makes a transition
1971 through Empty connection to always-clear connection and
1972 instantiates a pass-through policy at the forwarding plane.)
1974 (10) Datagram is seen at Alice's gateway.
1976 (11) OS hands datagram to application. Alice sends another datagram.
1978 (12) A second datagram traverses the Internet.
1981 11.2 Opportunistic encryption
1983 In the presence of properly configured opportunistic encryptors, the
1984 event list is extended.
1986 ---------------------------------------------------------------------
1989 Alice SG-A DNS SG-B Bob
1991 ------(2)-------------->
1992 <-----(3)---------------
1996 ~~~~~~~~~~~~~(5D)~~~>
1997 <~~~~~~~~~~~~(5E1)~~~
1998 ~~~~~~~~~~~~~(5E2)~~>
1999 <~~~~~~~~~~~~(5E3)~~~
2000 #############(5E4)##>
2001 <############(5E5)###
2004 #############(5G1)##>
2007 <############(5G2)###
2008 #############(5G3)##>
2009 ============(6)====>
2015 Richardson & Redelmeier Expires November 19, 2003 [Page 36]
2017 Internet-Draft opportunistic May 2003
2020 <==========(9)======
2023 ==========(12)=====>
2026 <===================
2029 Figure 6: Timing of opportunistic encryption transaction
2031 ---------------------------------------------------------------------
2033 (1) Human or application clicks with a name.
2035 (2) Application initiates DNS mapping.
2037 (3) Resolver returns A record to application.
2039 (4) Application starts a TCP session or UDP.
2041 (5) SG-A (host or SG) sees datagram to target, and buffers it.
2043 (5B) SG-A asks DNS for TXT record.
2045 (5C) DNS returns TXT record(s).
2047 (5D) Initial IKE Main Mode Packet goes out.
2049 (5E) IKE ISAKMP phase 1 succeeds.
2051 (5F) SG-B asks DNS for TXT record to prove SG-A is an agent for
2054 (5G) IKE phase 2 negotiation.
2056 (5H) DNS lookup by responder (SG-B).
2058 (6) Buffered datagram is sent by SG-A.
2060 (7) Datagram is received by SG-B, decrypted, and sent to Bob.
2062 (8) Bob replies, and datagram is seen by SG-B.
2064 (9) SG-B already has tunnel up with SG-A, and uses it.
2066 (10) SG-A decrypts datagram and gives it to Alice.
2071 Richardson & Redelmeier Expires November 19, 2003 [Page 37]
2073 Internet-Draft opportunistic May 2003
2076 (11) Alice receives datagram. Sends new packet to Bob.
2078 (12) SG-A gets second datagram, sees that tunnel is up, and uses it.
2080 For the purposes of this section, we will describe only the changes
2081 that occur between Figure 5 and Figure 6. This corresponds to time
2082 points 5, 6, 7, 9 and 10 on the list above.
2084 11.2.1 (5) IPsec datagram interception
2086 At point (5), SG-A intercepts the datagram because this source/
2087 destination pair lacks a policy (the non-existent policy state). SG-
2088 A creates a hold policy, and buffers the datagram. SG-A requests
2089 keys from the keying daemon.
2091 11.2.2 (5B) DNS lookup for TXT record
2093 SG-A's IKE daemon, having looked up the source/destination pair in
2094 the connection class list, creates a new Potential OE connection
2095 instance. SG-A starts DNS queries.
2097 11.2.3 (5C) DNS returns TXT record(s)
2099 DNS returns properly formed TXT delegation records, and SG-A's IKE
2100 daemon causes this instance to make a transition from Potential OE
2101 connection to Pending OE connection.
2103 Using the example above, the returned record might contain:
2105 ---------------------------------------------------------------------
2108 X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
2110 Figure 7: Example of reverse delegation record for Bob
2112 ---------------------------------------------------------------------
2114 with SG-B's IP address and public key listed.
2116 11.2.4 (5D) Initial IKE main mode packet goes out
2118 Upon entering Pending OE connection, SG-A sends the initial ISAKMP
2119 message with proposals. See Section 4.6.1.
2121 11.2.5 (5E1) Message 2 of phase 1 exchange
2123 SG-B receives the message. A new connection instance is created in
2127 Richardson & Redelmeier Expires November 19, 2003 [Page 38]
2129 Internet-Draft opportunistic May 2003
2132 the unauthenticated OE peer state.
2134 11.2.6 (5E2) Message 3 of phase 1 exchange
2136 SG-A sends a Diffie-Hellman exponent. This is an internal state of
2139 11.2.7 (5E3) Message 4 of phase 1 exchange
2141 SG-B responds with a Diffie-Hellman exponent. This is an internal
2142 state of the keying protocol.
2144 11.2.8 (5E4) Message 5 of phase 1 exchange
2146 SG-A uses the phase 1 SA to send its identity under encryption. The
2147 choice of identity is discussed in Section 4.6.1. This is an
2148 internal state of the keying protocol.
2150 11.2.9 (5F1) Responder lookup of initiator key
2152 SG-B asks DNS for the public key of the initiator. DNS looks for a
2153 KEY record by IP address in the reverse-map. That is, a KEY resource
2154 record is queried for 4.1.1.192.in-addr.arpa (recall that SG-A's
2155 external address is 192.1.1.4). SG-B uses the resulting public key
2156 to authenticate the initiator. See Section 5.1 for further details.
2158 11.2.10 (5F2) DNS replies with public key of initiator
2160 Upon successfully authenticating the peer, the connection instance
2161 makes a transition to authenticated OE peer on SG-B.
2163 The format of the TXT record returned is described in Section 5.2.
2165 11.2.11 (5E5) Responder replies with ID and authentication
2167 SG-B sends its ID along with authentication material. This is an
2168 internal state for the keying protocol.
2170 11.2.12 (5G) IKE phase 2
2172 11.2.12.1 (5G1) Initiator proposes tunnel
2174 Having established mutually agreeable authentications (via KEY) and
2175 authorizations (via TXT), SG-A proposes to create an IPsec tunnel for
2176 datagrams transiting from Alice to Bob. This tunnel is established
2177 only for the Alice/Bob combination, not for any subnets that may be
2178 behind SG-A and SG-B.
2183 Richardson & Redelmeier Expires November 19, 2003 [Page 39]
2185 Internet-Draft opportunistic May 2003
2188 11.2.12.2 (5H1) Responder determines initiator's authority
2190 While the identity of SG-A has been established, its authority to
2191 speak for Alice has not yet been confirmed. SG-B does a reverse
2192 lookup on Alice's address for a TXT record.
2194 Upon receiving this specific proposal, SG-B's connection instance
2195 makes a transition into the potential OE connection state. SG-B may
2196 already have an instance, and the check is made as described above.
2198 11.2.12.3 (5H2) DNS replies with TXT record(s)
2200 The returned key and IP address should match that of SG-A.
2202 11.2.12.4 (5G2) Responder agrees to proposal
2204 Should additional communication occur between, for instance, Dave and
2205 Bob using SG-A and SG-B, a new tunnel (phase 2 SA) would be
2206 established. The phase 1 SA may be reusable.
2208 SG-A, having successfully keyed the tunnel, now makes a transition
2209 from Pending OE connection to Keyed OE connection.
2211 The responder MUST setup the inbound IPsec SAs before sending its
2214 11.2.12.5 (5G3) Final acknowledgment from initiator
2216 The initiator agrees with the responder's choice and sets up the
2217 tunnel. The initiator sets up the inbound and outbound IPsec SAs.
2219 The proper authorization returned with keys prompts SG-B to make a
2220 transition to the keyed OE connection state.
2222 Upon receipt of this message, the responder may now setup the
2225 11.2.13 (6) IPsec succeeds, and sets up tunnel for communication between
2228 SG-A sends the datagram saved at step (5) through the newly created
2229 tunnel to SG-B, where it gets decrypted and forwarded. Bob receives
2230 it at (7) and replies at (8).
2232 11.2.14 (9) SG-B already has tunnel up with G1 and uses it
2234 At (9), SG-B has already established an SPD entry mapping Bob->Alice
2235 via a tunnel, so this tunnel is simply applied. The datagram is
2239 Richardson & Redelmeier Expires November 19, 2003 [Page 40]
2241 Internet-Draft opportunistic May 2003
2244 encrypted to SG-A, decrypted by SG-A and passed to Alice at (10).
2295 Richardson & Redelmeier Expires November 19, 2003 [Page 41]
2297 Internet-Draft opportunistic May 2003
2300 12. Security considerations
2302 12.1 Configured vs opportunistic tunnels
2304 Configured tunnels are those which are setup using bilateral
2305 mechanisms: exchanging public keys (raw RSA, DSA, PKIX), pre-shared
2306 secrets, or by referencing keys that are in known places
2307 (distinguished name from LDAP, DNS). These keys are then used to
2308 configure a specific tunnel.
2310 A pre-configured tunnel may be on all the time, or may be keyed only
2311 when needed. The end points of the tunnel are not necessarily
2312 static: many mobile applications (road warrior) are considered to be
2315 The primary characteristic is that configured tunnels are assigned
2316 specific security properties. They may be trusted in different ways
2317 relating to exceptions to firewall rules, exceptions to NAT
2318 processing, and to bandwidth or other quality of service
2321 Opportunistic tunnels are not inherently trusted in any strong way.
2322 They are created without prior arrangement. As the two parties are
2323 strangers, there MUST be no confusion of datagrams that arrive from
2324 opportunistic peers and those that arrive from configured tunnels. A
2325 security gateway MUST take care that an opportunistic peer can not
2326 impersonate a configured peer.
2328 Ingress filtering MUST be used to make sure that only datagrams
2329 authorized by negotiation (and the concomitant authentication and
2330 authorization) are accepted from a tunnel. This is to prevent one
2331 peer from impersonating another.
2333 An implementation suggestion is to treat opportunistic tunnel
2334 datagrams as if they arrive on a logical interface distinct from
2335 other configured tunnels. As the number of opportunistic tunnels
2336 that may be created automatically on a system is potentially very
2337 high, careful attention to scaling should be taken into account.
2339 As with any IKE negotiation, opportunistic encryption cannot be
2340 secure without authentication. Opportunistic encryption relies on
2341 DNS for its authentication information and, therefore, cannot be
2342 fully secure without a secure DNS. Without secure DNS, opportunistic
2343 encryption can protect against passive eavesdropping but not against
2344 active man-in-the-middle attacks.
2351 Richardson & Redelmeier Expires November 19, 2003 [Page 42]
2353 Internet-Draft opportunistic May 2003
2356 12.2 Firewalls versus Opportunistic Tunnels
2358 Typical usage of per datagram access control lists is to implement
2359 various kinds of security gateways. These are typically called
2362 Typical usage of a virtual private network (VPN) within a firewall is
2363 to bypass all or part of the access controls between two networks.
2364 Additional trust (as outlined in the previous section) is given to
2365 datagrams that arrive in the VPN.
2367 Datagrams that arrive via opportunistically configured tunnels MUST
2368 not be trusted. Any security policy that would apply to a datagram
2369 arriving in the clear SHOULD also be applied to datagrams arriving
2372 12.3 Denial of service
2374 There are several different forms of denial of service that an
2375 implementor should concern themselves with. Most of these problems
2376 are shared with security gateways that have large numbers of mobile
2377 peers (road warriors).
2379 The design of ISAKMP/IKE, and its use of cookies, defend against many
2380 kinds of denial of service. Opportunism changes the assumption that
2381 if the phase 1 (ISAKMP) SA is authenticated, that it was worthwhile
2382 creating. Because the gateway will communicate with any machine, it
2383 is possible to form phase 1 SAs with any machine on the Internet.
2407 Richardson & Redelmeier Expires November 19, 2003 [Page 43]
2409 Internet-Draft opportunistic May 2003
2412 13. IANA Considerations
2414 There are no known numbers which IANA will need to manage.
2463 Richardson & Redelmeier Expires November 19, 2003 [Page 44]
2465 Internet-Draft opportunistic May 2003
2470 Substantive portions of this document are based upon previous work by
2473 Thanks to Tero Kivinen, Sandy Harris, Wes Hardarker, Robert
2474 Moskowitz, Jakob Schlyter, Bill Sommerfeld, John Gilmore and John
2475 Denker for their comments and constructive criticism.
2477 Sandra Hoffman and Bill Dickie did the detailed proof reading and
2519 Richardson & Redelmeier Expires November 19, 2003 [Page 45]
2521 Internet-Draft opportunistic May 2003
2524 Normative references
2526 [1] Redelmeier, D. and H. Spencer, "Opportunistic Encryption",
2527 paper http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/
2528 opportunism.spec, May 2001.
2530 [2] Defense Advanced Research Projects Agency (DARPA), Information
2531 Processing Techniques Office and University of Southern
2532 California (USC)/Information Sciences Institute, "Internet
2533 Protocol", STD 5, RFC 791, September 1981.
2535 [3] Braden, R. and J. Postel, "Requirements for Internet gateways",
2536 RFC 1009, June 1987.
2538 [4] IAB, IESG, Carpenter, B. and F. Baker, "IAB and IESG Statement
2539 on Cryptographic Technology and the Internet", RFC 1984, August
2542 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
2543 Levels", BCP 14, RFC 2119, March 1997.
2545 [6] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management API,
2546 Version 2", RFC 2367, July 1998.
2548 [7] Kent, S. and R. Atkinson, "Security Architecture for the
2549 Internet Protocol", RFC 2401, November 1998.
2551 [8] Piper, D., "The Internet IP Security Domain of Interpretation
2552 for ISAKMP", RFC 2407, November 1998.
2554 [9] Maughan, D., Schneider, M. and M. Schertler, "Internet Security
2555 Association and Key Management Protocol (ISAKMP)", RFC 2408,
2558 [10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
2559 RFC 2409, November 1998.
2561 [11] Kivinen, T. and M. Kojo, "More MODP Diffie-Hellman groups for
2562 IKE", RFC 3526, March 2003.
2564 [12] Mockapetris, P., "Domain names - concepts and facilities", STD
2565 13, RFC 1034, November 1987.
2567 [13] Mockapetris, P., "Domain names - implementation and
2568 specification", STD 13, RFC 1035, November 1987.
2570 [14] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
2575 Richardson & Redelmeier Expires November 19, 2003 [Page 46]
2577 Internet-Draft opportunistic May 2003
2580 [15] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary
2581 String Attributes", RFC 1464, May 1993.
2583 [16] Eastlake, D., "Domain Name System Security Extensions", RFC
2586 [17] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
2587 System (DNS)", RFC 3110, May 2001.
2589 [18] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
2590 Domain Name System (DNS)", RFC 2538, March 1999.
2592 [19] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A.
2593 Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
2596 [20] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
2597 (NAT) Terminology and Considerations", RFC 2663, August 1999.
2602 Michael C. Richardson
2603 Sandelman Software Works
2608 EMail: mcr@sandelman.ottawa.on.ca
2609 URI: http://www.sandelman.ottawa.on.ca/
2617 EMail: hugh@mimosa.com
2631 Richardson & Redelmeier Expires November 19, 2003 [Page 47]
2633 Internet-Draft opportunistic May 2003
2636 Full Copyright Statement
2638 Copyright (C) The Internet Society (2003). All Rights Reserved.
2640 This document and translations of it may be copied and furnished to
2641 others, and derivative works that comment on or otherwise explain it
2642 or assist in its implementation may be prepared, copied, published
2643 and distributed, in whole or in part, without restriction of any
2644 kind, provided that the above copyright notice and this paragraph are
2645 included on all such copies and derivative works. However, this
2646 document itself may not be modified in any way, such as by removing
2647 the copyright notice or references to the Internet Society or other
2648 Internet organizations, except as needed for the purpose of
2649 developing Internet standards in which case the procedures for
2650 copyrights defined in the Internet Standards process must be
2651 followed, or as required to translate it into languages other than
2654 The limited permissions granted above are perpetual and will not be
2655 revoked by the Internet Society or its successors or assigns.
2657 This document and the information contained herein is provided on an
2658 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2659 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2660 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2661 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2662 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2666 Funding for the RFC Editor function is currently provided by the
2687 Richardson & Redelmeier Expires November 19, 2003 [Page 48]