Network Working Group M. Richardson Internet-Draft SSW |Expires: July 1, 2002 D. Redelmeier Mimosa H. Spencer SP Systems | December 31, 2001 A method for doing opportunistic encryption with IKE | draft-richardson-ipsec-opportunistic-04.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." | The list of current Internet-Drafts can be accessed at http:// | www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. | This Internet-Draft will expire on July 1, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. |Richardson, et al. Expires July 1, 2002 [Page 1] |Internet-Draft opportunistic December 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Types of network traffic . . . . . . . . . . . . . . . . . 5 1.2 Authentication of Opportunistic Encryption . . . . . . . . 6 2. Terminology and Reference diagrams . . . . . . . . . . . . 8 2.1 Reference diagram . . . . . . . . . . . . . . . . . . . . 8 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 | 3. Brief overview of method used . . . . . . . . . . . . . . 11 | 3.1 Plain-text usage (permit policy) . . . . . . . . . . . . . 11 | 3.2 Opportunistic Encryption . . . . . . . . . . . . . . . . . 12 | 4. Detailed description of process . . . . . . . . . . . . . 14 | 4.1 (5) IPsec packet interception . . . . . . . . . . . . . . 14 | 4.2 (5B) DNS lookup for TXT record . . . . . . . . . . . . . . 14 | 4.3 (5C) DNS returns TXT record(s) . . . . . . . . . . . . . . 14 | 4.4 (5D) Initial IKE Main Mode Packet goes out . . . . . . . . 15 | 4.5 (5E1) Message 2 of phase 1 exchange . . . . . . . . . . . 15 | 4.6 (5E2) Message 3 of phase 1 exchange . . . . . . . . . . . 15 | 4.7 (5E3) Message 4 of phase 1 exchange . . . . . . . . . . . 15 | 4.8 (5E4) Message 5 of phase 1 exchange . . . . . . . . . . . 15 | 4.9 (5F1) Responder lookup of initiator key . . . . . . . . . 15 | 4.10 (5F2) DNS replies with public key of initiator . . . . . . 15 | 4.11 (5E5) Responder replies with ID and authentication . . . . 16 | 4.12 (5G) IKE phase 2 . . . . . . . . . . . . . . . . . . . . . 16 | 4.12.1 (5G1) Initiator proposes tunnel . . . . . . . . . . . . . 16 | 4.12.2 (5H1) Responder determines initiator's authority . . . . . 16 | 4.12.3 (5H2) DNS replies with TXT record . . . . . . . . . . . . 16 | 4.12.4 (5G2) Responder agrees to proposal . . . . . . . . . . . . 16 | 4.12.5 (5G3) Final acknowledgement from initiator . . . . . . . . 16 4.13 (6) IPsec succeeds, sets up tunnel for communication | between Alice and Bob . . . . . . . . . . . . . . . . . . 16 | 4.14 (9) SG-B already has tunnel up with G1, uses it . . . . . 16 | 5. Renewal and Teardown . . . . . . . . . . . . . . . . . . . 17 | 5.1 Aging . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 5.2 Teardown and Cleanup . . . . . . . . . . . . . . . . . . . 18 | 6. Impacts on IKE . . . . . . . . . . . . . . . . . . . . . . 19 | 6.1 ISAKMP/IKE protocol . . . . . . . . . . . . . . . . . . . 19 | 6.2 Gateway discovery process . . . . . . . . . . . . . . . . 19 | 6.3 Self identification . . . . . . . . . . . . . . . . . . . 19 | 6.4 Public key Retrieval process . . . . . . . . . . . . . . . 20 | 6.5 Interactions with DNSSEC . . . . . . . . . . . . . . . . . 20 | 6.6 Recommended proposal types . . . . . . . . . . . . . . . . 20 | 6.6.1 Phase 1 IDs . . . . . . . . . . . . . . . . . . . . . . . 20 | 6.6.2 Phase 2 IDs . . . . . . . . . . . . . . . . . . . . . . . 21 | 7. DNS issues . . . . . . . . . . . . . . . . . . . . . . . . 22 | 7.1 Use of KEY record . . . . . . . . . . . . . . . . . . . . 22 | 7.2 Use of TXT delegation record . . . . . . . . . . . . . . . 22 | 7.2.1 Choice of TXT record . . . . . . . . . . . . . . . . . . . 24 |Richardson, et al. Expires July 1, 2002 [Page 2] |Internet-Draft opportunistic December 2001 | 7.3 Use of FQDN IDs . . . . . . . . . . . . . . . . . . . . . 24 | 8. Network Address Translation interaction . . . . . . . . . 26 | 8.1 Colocated NAT/NAPT . . . . . . . . . . . . . . . . . . . . 26 | 8.2 SG-A behind NAT/NAPT . . . . . . . . . . . . . . . . . . . 26 | 8.3 Bob is behind a NAT/NAPT . . . . . . . . . . . . . . . . . 26 | 9. Host implementations . . . . . . . . . . . . . . . . . . . 28 | 10. Multihoming . . . . . . . . . . . . . . . . . . . . . . . 29 | 11. Failure modes . . . . . . . . . . . . . . . . . . . . . . 31 | 11.1 DNS failures . . . . . . . . . . . . . . . . . . . . . . . 31 | 11.2 DNS configured, IKE failures . . . . . . . . . . . . . . . 31 | 11.3 System reboots . . . . . . . . . . . . . . . . . . . . . . 31 | 12. Unresolved issues . . . . . . . . . . . . . . . . . . . . 33 | 12.1 Control of reverse DNS . . . . . . . . . . . . . . . . . . 33 | 13. Security Considerations . . . . . . . . . . . . . . . . . 34 | 13.1 Configured vs Opportunistic Tunnels . . . . . . . . . . . 34 | 13.2 Firewalls vs Opportunistic Tunnels . . . . . . . . . . . . 34 | 13.3 Denial of Service . . . . . . . . . . . . . . . . . . . . 35 | 14. IANA Considerations . . . . . . . . . . . . . . . . . . . 36 | References . . . . . . . . . . . . . . . . . . . . . . . . 37 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . 38 | Full Copyright Statement . . . . . . . . . . . . . . . . . 39 |Richardson, et al. Expires July 1, 2002 [Page 3] |Internet-Draft opportunistic December 2001 Abstract | This document describes opportunistic encryption using IKE and IPsec. | The objective is to allow encryption without any pre-arrangement | specific to the pair of gateways involved. Each gateway | administrator makes local arrangements to support opportunistic | encryption. Once that is done, any two such gateways can communicate | securely. | There are two large payoffs. First, if many machines must | communicate securely, this approach reduces administrative overhead | to order N (number of gateways), rather than the N squared cost to | configure each tunnel separately. Second, it becomes possible to | make secure communication the default, even when the partner is not | known in advance. | There are naturally some risks and some costs, which are described. This document is offered up as an Informational RFC. |Richardson, et al. Expires July 1, 2002 [Page 4] |Internet-Draft opportunistic December 2001 1. Introduction | The objective of opportunistic encryption is to allow encryption | without any pre-arrangement specific to the pair of gateways | involved. Each gateway administrator makes local arrangements -- | specifically, adds public key information to DNS records -- to | support opportunistic encryption. Once that is done, any two such | gateways can communicate securely. | This document describes opportunistic encryption as designed and (to | date, partially) implemented by the Linux FreeS/WAN project. For | project information, see www.freeswan.org. The Internet Architecture Board (IAB) and Internet Engineering Steering Group have taken a strong stand that the Internet should | use powerful encryption to provide security and privacy [2]. This project attempts to put this policy into practice by providing practical means to implement them. | The project believes that the IPsec protocols are the best chance to | do that, because they are standardised, widely available and can | often be deployed very easily, without changing hardware or software | or retraining of users. However, the extension to opportunistic | encryption seems necessary, both to help control administrative | overheads and to get IPsec more widely used. The use of "opportunistic encryption" offers the "fax effect". As each person installs one for their own use, it becomes more valuable for their neighbors to install one too, because there's one more person to use it with. The software automatically notices each newly installed box, and doesn't require a network administrator to reconfigure it. This document describes the infrastructure needed to support this effort. The term S/WAN is a trademark of RSA Data Systems, and is used with permission by this project. 1.1 Types of network traffic To aid in understand the relationship between security processing and IPsec we divide network traffic into four categories: deny networks to which traffic is always forbidden permit networks to which traffic in the clear is desired |Richardson, et al. Expires July 1, 2002 [Page 5] |Internet-Draft opportunistic December 2001 | opportunistic tunnel networks to which encryption should be done | if possible, but sent in the clear otherwise | configured tunnel networks to which encryption must be done, and never sent in the clear This document describes the third category. The first two categories are provided by traditional firewall devices. The fourth category is presently the offering of many Virtual Private Network (VPN) devices. Category one, denied traffic by IP address, requires no authentication. Category two, permitted traffic by IP address, requires no authentication. This is the normal default on the Internet. Category four, encrypt traffic or drop it, requires authentication of the end points. As the number of end points is typically bound and is typically under the authority of a single authority, arranging for exchange of authentication material, while difficult, does not require any new technology. The mechanism described here provide an additional way to provide the authentication materials, notably a public key method that does not require deployment of an X.509 based infrastructure. 1.2 Authentication of Opportunistic Encryption Opportunistic encryption involves creating tunnels with other nodes with are essentially strangers. This is done without any prior bilateral arrangement. There is therefore the difficult question of how does one know who one is talking to. One answer is that one does not know who one is talking to. No useful authentication can be done, so do not even try. This mode of operation has been given the name "anonymous encryption". Although a useful mode, it is not the goal of this project. It is a useful starting point, but the system should permit additional layers of trust to be built upon this system. In the described system, the anonymous encryption case is what results without DNSSEC. Were anonymous encryption the end goal, simpler methods are available to achieve this goal. However, an essential premise of building private connections with strangers is that packets received through these opportunist tunnels packets are no more special than packets that arrived in the clear. Unlike in a VPN scenario, these packets should not be given any |Richardson, et al. Expires July 1, 2002 [Page 6] |Internet-Draft opportunistic December 2001 | special exceptions when it comes to auditing, further authentication | or firewalling. | On the outbound side, when initiating opportunistic encryption, it becomes a local matter what to do if one fails to setup a tunnel. It may be that the packet goes out in the clear, or it may be dropped. This is a local configuration matter. In sum, we gain wider privacy (for the Internet at large) at minimal cost: the cost is the need to reassess assumptions about the relationship between IPsec authentication and further local access control. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this | document, are to be interpreted as described in [3] |Richardson, et al. Expires July 1, 2002 [Page 7] |Internet-Draft opportunistic December 2001 2. Terminology and Reference diagrams 2.1 Reference diagram | --------------------------------------------------------------------- The following network diagram is used in the rest of this document as the canonical diagram [Q] [R] AS2 . . [A]----+----[SG-A]...+....+....[SG-B]-------[B] AS1 | . PI . [D]----+----[SG-D]...+ +....[C] AS3 | Figure 1: Reference Network Diagram | --------------------------------------------------------------------- In this diagram, there are four end-nodes: A, B, C and D. There are three gateways, SG-A, SG-B, SG-D. A, D, SG-A and SG-D are part of the same administrative authority. SG-A and SG-D are on two different exit paths from organization 1. SG-B/B is an independent organizations. Nodes Q and R are nodes that are on the Internet. PI is the Public Internet ("The Wild"). 2.2 Terminology The following terminology is used in this document: security gateway: a system that performs IPsec tunnel mode encapsulation/decapsulation. [Gx] in the diagram | Alice: node [A] in the diagram. When an IP address is needed, | this is 192.1.0.65. | Bob: node [B] in the diagram. When an IP address is needed, this | is 192.2.0.66. | Carol: node [C] in the diagram. When an IP address is needed, | this is 192.1.1.67. | Dave: node [D] in the diagram. When an IP address is needed, this | is 192.3.0.68 SG-A Alice's security gateway. Internally it is 192.1.0.1, |Richardson, et al. Expires July 1, 2002 [Page 8] |Internet-Draft opportunistic December 2001 | externally it is 192.1.1.4. | SG-B Bob's security gateway. Internally it is 192.2.0.1, | externally it is 192.1.1.5. | SG-D Dave's security gateway. Also Alice's backup security | gateway. Internally it is 192.3.0.1, externally it is | 192.1.1.6. - a single dash represents clear-text packets = an equals sign represents phase 2 (IPsec) cipher-text packets # a hash sign represents phase 1 (IKE) cipher-text packets . a period represents an untrusted network of unknown type | configured tunnel: Contrast with opportunistic tunnel. A tunnel | that is directly/deliberately/hand configured on participating | gateways. Configured tunnel are typically given a higher level | of trust than opportunistic tunnels. | road warrior tunnel: a configured tunnel connecting one node with | a fixed IP address and one node with a variable IP address. A | road warrior (RW) connection must be initiated by the variable | node, since the fixed node does not know what the address for | the "road warrior" currently is. | phase 1 SA an ISAKMP/IKE security association, sometimes also | referred to as a keying channel. phase 2 SA an IPsec security association tunnel another term for a set of phase 2 SA | NAT Network Address Translation (see [13]) | NAPT Network Address and Port Translation (see [13]) | anonymous encryption: The process of encrypting a session without | any knowledge of who the receiving party is. That is, no authentication of identities is done. opportunistic encryption: The process of encrypting a session with knowledge of who the receiving party is. | lifetime: The negotiated period in seconds (bytes or packets) | which a security association will remain alive before needing |Richardson, et al. Expires July 1, 2002 [Page 9] |Internet-Draft opportunistic December 2001 | to be rekeyed. | lifespan: The effective time which a security association remains | useful. A security association with a lifespan shorter than | its lifetime would be removed when no longer needed. A | security association with a lifespan longer than its lifetime | would need to be rekeyed one or more times. |Richardson, et al. Expires July 1, 2002 [Page 10] |Internet-Draft opportunistic December 2001 3. Brief overview of method used 3.1 Plain-text usage (permit policy) | --------------------------------------------------------------------- Alice Gate1 DNS Gate2 Bob (1) ------(2)--------------> <-----(3)--------------- (4)----(5)----->----------(6)------>------(7)-----> <----(10)-----<----------(9)------<------(8)------ (11)----------->----------(12)----->--------------> <-------------<-------------------<--------------- | Figure 2: Timing of regular transaction | --------------------------------------------------------------------- Alice wants to send a packet to Bob, say a ping packet. Without the presence of opportunistic encryptors, the following events occur: (1) Human or application 'clicks' with a name (2) Application looks up name in DNS to get IP address (3) Resolver returns A record to application | (4) Application starts a TCP session or UDP session, OS sends | packet (5) Packet is seen at first gateway from Alice (SG-A) (6) Packet is seen at last gateway before Bob (SG-B) (7) First packet from Alice is seen by Bob (8) First return packet is sent by Bob (9) Packet is seen at Bob's gateway (10) Packet is seen at Alice's gateway (11) OS hands packet to application, Alice sends another packet (12) a second packet traverses the Internet |Richardson, et al. Expires July 1, 2002 [Page 11] |Internet-Draft opportunistic December 2001 |3.2 Opportunistic Encryption | In the presence of properly configured opportunistic encryptors, the | event list is extended. | --------------------------------------------------------------------- | Alice SG-A DNS SG-B Bob (1) ------(2)--------------> <-----(3)--------------- (4)----(5)----->+ ----(5B)-> <---(5C)-- -------------(5D)---> <------------(5E1)--- | -------------(5E2)--> | <------------(5E3)--- #############(5E4)##> <############(5E5)### <----(5F1)-- -----(5F2)-> #############(5G1)##> | <----(5H1)-- | -----(5H2)-> | <############(5G2)### | #############(5G3)##> ============(6)====>------(7)-----> <-----(10)----<==========(9)======<------(8)------ (11)----------->==========(12)=====>--------------> <-------------<===================<--------------- | Figure 3: Timing of Opportunistic Encryption transaction | --------------------------------------------------------------------- (1) Human or application clicks with a name (2) Application initiates DNS mapping. (3) resolver returns A record to application (4) Application starts a TCP session or UDP (5) SG (host or SG) sees packet to target, buffers it. (5B) SG asks the DNS for TXT record |Richardson, et al. Expires July 1, 2002 [Page 12] |Internet-Draft opportunistic December 2001 | (5C) DNS returns TXT record(s) | (5D) Initial IKE Main Mode Packet goes out | (5E) IKE ISAKMP phase 1 succeeds | (5F) SG-B asks the DNS for TXT record to prove SG-A agent for | Alice | (5G) IKE phase 2 negotiation | (5H) DNS looksup by responder (SG-B) (6) buffered packet is sent by SG-A (7) packet is received by SG-B, and decrypted, sent to Bob (8) Bob replies, packet is seen by SG-B (9) SG-B already has tunnel up with SG-A, uses it (10) SG-A decrypts packet and give it to Alice (11) Alice receives packet. Sends new packet to Bob (12) SG-A gets second packet, sees that tunnel is up, uses it |Richardson, et al. Expires July 1, 2002 [Page 13] |Internet-Draft opportunistic December 2001 4. Detailed description of process For the purposes of this section, we will describe on the changes that occur between Figure 2 and Figure 3. This means time points 5, 6, 7, 9 and 10. 4.1 (5) IPsec packet interception At point (5), the Security Gateway intercepts the packet, as it would with any configured tunnel. The packet is buffered. If there is already a buffered packet that matches the same selectors, the new packet is dropped. There are no differences from regular IPsec processing here. At the IPsec SPD level, opportunistic encryption may be considered as | being simply a per-host keyed (see [4] section 4.4.1) tunnel to 0.0.0.0/0. Should the prospective responder not have OE configured (or: not respond to attempts to establish a phase 1 SA), the initiator MAY create an SPD entry to permit clear-text packets to this machine. This is a local policy decision. In the configured tunnel situation the packet would never be sent in the clear. 4.2 (5B) DNS lookup for TXT record The IKE daemon, having been informed of the need for a tunnel between Alice and Bob performs a DNS lookup. This DNS lookup serves two purposes: 1. to find the public key of the responding gateway (SG-B) 2. to find out the IP address of this gateway (SG-B) A reverse lookup is done on the IP address of Bob, mapped into the in-addr.arpa in the usual way. The lookup requests TXT records. These are interpreted as described in Section 7.2. 4.3 (5C) DNS returns TXT record(s) Given the IP address of the gateway information, SG-A is now in a position to create a phase 1 SA with SG-B. For the example above, the returned record might contain: |Richardson, et al. Expires July 1, 2002 [Page 14] |Internet-Draft opportunistic December 2001 | --------------------------------------------------------------------- | X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== | Figure 4: Example of reverse delegation record | --------------------------------------------------------------------- with SG-B's IP address and public key listed. 4.4 (5D) Initial IKE Main Mode Packet goes out SG-A sends the initial ISAKMP message, with proposals, see Section 6.6.1. 4.5 (5E1) Message 2 of phase 1 exchange SG-B receives the message and responds with its choice of proposals for the phase 1 SA. 4.6 (5E2) Message 3 of phase 1 exchange SG-A sends a Diffie-Hellman exponent. 4.7 (5E3) Message 4 of phase 1 exchange SG-B responds with a Diffie-Hellman exponent. 4.8 (5E4) Message 5 of phase 1 exchange SG-A uses the phase 1 SA to send its identity under encryption. The choice of identity is discussed in Section 6.6.1. 4.9 (5F1) Responder lookup of initiator key Security Gateway 2 asks DNS for the public key of the initiator. This is done by asking for a KEY record by IP address in the reverse map. That is, a KEY resource record is queried for 4.1.1.192.in- addr.arpa (recall that SG-A's external address is 192.1.1.4) The resulting public key is used to authenticate the initiator. See Section 7.1 for further details. 4.10 (5F2) DNS replies with public key of initiator The format of the KEY record is described in Section 7.1. The format of the TXT record that is returned is described in Section |Richardson, et al. Expires July 1, 2002 [Page 15] |Internet-Draft opportunistic December 2001 | 7.2. |4.11 (5E5) Responder replies with ID and authentication | SG-B sends its ID along with authentication material. |4.12 (5G) IKE phase 2 4.12.1 (5G1) Initiator proposes tunnel Having established mutually agreeable authentications (via KEY) and authorizations (via TXT), SG-A proposes to create an IPsec tunnel for packets transiting from Alice to Bob. This tunnel is established for only the A/B combination, not for any subnets that may be behind SG-A and SG-B. |4.12.2 (5H1) Responder determines initiator's authority While the identity of the SG-A has been established, its authority to speak for Alice has not yet been confirmed. This is done by doing a reverse lookup on A's address for a TXT record. \ |4.12.3 (5H2) DNS replies with TXT record The returned key and IP address should match that of SG-A. |4.12.4 (5G2) Responder agrees to proposal Should additional communication occur between, for instance, D and B via SG-A and SG-B, a new tunnel (phase 2 SA) would be established. The phase 1 SA may be reusable. |4.12.5 (5G3) Final acknowledgement from initiator | The initiator agree with the responder's choice and sets up the | tunnel. 4.13 (6) IPsec succeeds, sets up tunnel for communication between Alice and Bob The packet which was saved at step (5) is sent through the newly created tunnel to SG-B. Bob receives it at (7) and replies at (8). 4.14 (9) SG-B already has tunnel up with G1, uses it At (9), SG-B has already established an SPD entry mapping Bob->Alice via a tunnel, so this tunnel is simply applied. The packet is encrypted to SG-A, decrypted by SG-A and passed to Alice at (10). |Richardson, et al. Expires July 1, 2002 [Page 16] |Internet-Draft opportunistic December 2001 5. Renewal and Teardown 5.1 Aging When to tear tunnels down is a bit problematic, but as an a potentially unbounded number of them may be created, a mechanism to remove them is required. There are two methods in which the tunnel may be removed: by expiring or with explicit deletion. Explicit deletion is done with an IKE Delete message. To do this requires that both ends maintain the phase 1 ISAKMP SA, as the deletes must be authenticated. An implementation which refuses to maintain this SA will be unable to use this method. In the expiry method, the tunnel is simply allowed by the IKE daemon to expire rather than rekeying it. Regardless of which method is used, a method is required to determine if the tunnel is still in use. This is a local matter, but the following criteria are what is used by the FreeSWAN project. This criteria is currently implemented in the key management daemon, but could also be implemented at the SPD layer using an idle timer. | + a short initial (soft) lifespan of 1 minute is set. This is | done since many net flows in fact last only a few seconds. | + at the end of the lifespan, a check is made to see if the | tunnel was used by traffic in either direction during the last | half of this period. If so, assign a longer tentative | lifespan, of 20 minutes, after which, look again. If the | tunnel is not in use then close the tunnel. The tentative lifespan is independent of rekeying; it is just the time when the tunnel's future is next considered. (The term lifespan is used here rather than lifetime for this reason.) This should happen reasonably frequently, unlike rekeying, which is costly and shouldn't be too frequent. Multi-step backoff algorithms were cosnidered but are not worth the trouble; connections are considered to be either very short lived, or long lived. A poll every 20 minutes is not considered a problem. If the security gateway and the client host are one and the same, tunnel teardown decisions might wish to pay attention to TCP connection status, as reported by the local TCP layer. A still- open TCP connection is almost a guarantee that more traffic is |Richardson, et al. Expires July 1, 2002 [Page 17] |Internet-Draft opportunistic December 2001 coming, while the demise of the only TCP connection through a tunnel is a strong hint that no more traffic will transit. 5.2 Teardown and Cleanup Teardown should always be coordinated with the other end. This means interpreting and sending Delete notifications. On receiving a Delete for the outbound SAs of a tunnel (or some subset of them), tear down the inbound ones too, and notify the | other end with a Delete. If a Delete is received for a tunnel which | is no longer in existence, then two Delete messages have crossed | paths. Ignore the Delete - the operation has already been done. Do | not generate any messages in this situation. | Tunnels need to be considered as bidirectional entities, even though | the low-level protocols don't think of them that way. When the deletion is initiated locally, rather than as a response to a received Delete, send a Delete for (all) the inbound SAs of a tunnel. If no responding Delete is received for the outbound SAs, try re-sending the original Delete. Three tries spaced 10s apart seems a reasonable level of effort. A failure for the other end to respond at this point likely indicates that no further communication will be possible in anycase. After rekeying, transmission should switch to using the new SAs (ISAKMP or IPsec) immediately, and the old leftover SAs should be cleared out promptly (and Deletes sent) rather than waiting for them to expire. This reduces clutter and minimizes confusion. Since there is only one keying channel per remote IP address, the question of whether a Delete notification has appeared on a | ``suitable'' phase 1 SA does not arise. |Richardson, et al. Expires July 1, 2002 [Page 18] |Internet-Draft opportunistic December 2001 6. Impacts on IKE 6.1 ISAKMP/IKE protocol The IKE wire protocol needs no modifications. The major changes are implementation issues relating to how the proposals are interpreted, and from whom they may come. As Opportunistic Encryption is designed to be useful between peers without prior operator configuration, an IKE daemon must be prepared to negotiate phase 1 SAs with any node. This may require a large amount of resources to maintain cookie state, as well as large amounts of entropy to for nonces, cookies, etc. The major changes to support Opportunistic Encryption are at the IKE daemon level. These changes relate to handling of key acquisition requests, lookup of public keys and TXT records, and interactions with firewalls and other security facilities that may be coresident on the same gateway. 6.2 Gateway discovery process In a typical configured tunnel situation, the address of SG-B is provided via configuration. Furthermore, the mapping of SPD entry to gateway is typically a 1:1 mapping. When the 0.0.0.0/0 SPD entry technique is used, then the mapping to a gateway is determined by the reverse DNS records. The need to do a DNS lookup and wait for a reply will typically introduce a new state and a new event source (DNS replies) to IKE. Although a synchronous DNS request can be done for proof of concept, this will not scale very well. Use of an asychronous DNS lookup will also permit overlap of DNS lookups with protocol steps. 6.3 Self identification SG-A will have to establish its identity. This is done by use of an IPv4 ID in phase 1. There are many situations where the administrator of SG-A may not be able to control their reverse DNS. Typical situations include dialup connections and most residential-type broadband Internet access (ADSL, cable-modem). In these situations, a fully qualified domain name which is under the control of SG-A's administrator may be used. The FQDN ID should be used in phase 1. See Section 7.3 for more details and restrictions. |Richardson, et al. Expires July 1, 2002 [Page 19] |Internet-Draft opportunistic December 2001 6.4 Public key Retrieval process Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID, or an FQDN ID, an IKE daemon will need to examine local caches and configuration files to determine if this is part of a configured tunnel. If none is found, then the implementation should attempt to | retrieve a KEY record from the reverse DNS (in the case of an IPv4/ | IPv6 ID), or from the forward DNS in the case of FQDN ID. It is reasonable that if other non-local sources of policy are used (COPS, LDAP, ...) that they be consulted concurrently, but that some clear ordering of policy be provided. Note that due to variances in latency, one must wait for positive or negative replies from all sources of policy before making any decisions. 6.5 Interactions with DNSSEC The present implementation does not use DNSSEC to explicitly verify the authenticity of zone information, or use the NXT records to provide authentication of the absence of a TXT or KEY record. These are important considerations for practical use. In practice the verification of the DNSSEC SIG and NXT records will typically be done by a trusted DNS server. This process may be co- located, or reachable via a trusted path. 6.6 Recommended proposal types 6.6.1 Phase 1 IDs | Main mode MUST be used. | The initiator MUST offer at least one proposal using some combination | of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be | proposed first. [6] | The initiator MAY offer additional proposals, but the cipher MUST not | be weaker than 3DES. The initiator SHOULD limit the number of | proposals such that the IKE datagrams do not need to be fragmented. | The responder MUST accept one of the proposals. If any configuration | of the responder is required then the responder is not acting in an | opportunistic way. SG-A SHOULD use an ID_IPV4_ADDR, of the external interface of SG-A for phase 1. (There is an exception, see Section 7.3) The authentication method SHOULD be RSA public key signatures. |Richardson, et al. Expires July 1, 2002 [Page 20] |Internet-Draft opportunistic December 2001 | The RSA key for SG-A SHOULD be placed into a DNS KEY record in the | reverse space of SG-A. (i.e. using in-addr.arpa.) |6.6.2 Phase 2 IDs | SG-A SHOULD propose a tunnel between Alice and Bob, using 3DES-CBC mode, MD5 or SHA1 authentication. Perfect Forward Secrecy SHOULD be specified. Authorization for SG-A to act on Alice's behalf is determined by looking for a TXT record in the reverse map at Alice's address. |Richardson, et al. Expires July 1, 2002 [Page 21] |Internet-Draft opportunistic December 2001 7. DNS issues 7.1 Use of KEY record In order to establish its own identity, SG-A and SG-B must publish their public keys in their reverse DNS. This is just done via | DNSSEC's KEY record. See section 3 of RFC 2535 [9]. For example: KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8 | 0x4200 The flag bits, indicating that this key is prohibited for | use confidentiality (it authenticates the peer only, DH is used | for confidentiality), and that this key is associated with the | non-zone entity whose name is the RR owner name. No other | flags are set. 4 This indicates that this key is for use by IPsec 1 An RSA key is present | AQNJjkKlIk9...nYyUkKK8 the public key of the host as described in | [10] 7.2 Use of TXT delegation record A TXT record is published by Alice (Bob) to provide authorization for SG-A (SG-B) to act on their behalf. This record is located in the reverse DNS (in-addr.arpa) for them. The reverse DNS SHOULD be secured by DNSSEC, when it is deployed. DNSSEC is required to defend against active attacks. The mechanism described here provides a new way to change the routing of IP packets other than the routing system. As a matter of local policy, an implementation MAY ignore these records unless it is certain that they have been signed with DNSSEC. If Alice's address is P.Q.R.S, then she can authorize another node to act on her behalf by publishing records at: S.R.Q.P.in-addr.arpa | The contents of the resource record are expected to be a string that | follows the following syntax, as suggested in [8]. (Note that the | reply to query may include other resource records from other | applications may also be returned.) |Richardson, et al. Expires July 1, 2002 [Page 22] |Internet-Draft opportunistic December 2001 | --------------------------------------------------------------------- | X-IPsec-Server(P)=A.B.C.D KEY | Figure 5: Format of reverse delegation record | --------------------------------------------------------------------- | P: the P specifies a precedence for this record. This is similar | to MX record preferences. Lower numbers have stronger | preference. A.B.C.D: specifies the IP address of the Security Gateway for this client machine. | KEY: is the encoded RSA Public key of the Security Gateway. This | is provided here to avoid a second DNS lookup. If this field | is absent, then a KEY resource record should be looked up in | the reverse map of A.B.C.D. In the case where Alice is located at a public address behind a security gateway that has no fixed address (or no control over its reverse map), then Alice may delegate to a public key by domain name: | --------------------------------------------------------------------- X-IPsec-Server(P)=@FQDN KEY | Figure 6: Format of reverse delegation record (FQDN version | --------------------------------------------------------------------- P: is as above. FQDN specifies the FQDN that the Security Gateway will identify itself with. KEY: is the encoded RSA Public key of the Security Gateway. If there is more than one such TXT record with strongest (lowest numbered) precedence, one Security Gateway is picked arbitrarily from those specified in the strongest-preference records. All keys for | that Security Gateway are made available as candidates for signature | checking. This mechanism is required to permit rollover of signature | keys in a seamless fashion. |Richardson, et al. Expires July 1, 2002 [Page 23] |Internet-Draft opportunistic December 2001 7.2.1 Choice of TXT record | It has been suggested to use the OPT, CERT, KEY or KX records instead | of a TXT record. They KEY RR has a Protocol field which could be used to indicate use for a new protocol, and an Algorithm field which could be used to indicate different contents in the key data. However, the KEY record is not clearly indended for storing what are really authorizations, it is just for identities. Other uses have been discouraged. | OPT resource records, as defined in [7] are not intended to be used for storage of information. They are not to be loaded, cached or forwarded. They are therefore inappropriate for use here. | CERT records [11] can encode almost any set of information. A custom Type code would be used permitting any suitable encoding to be stored, not just X.509. The certificate according to the RFC, are signed internally, which may add undesireable and unnecessary bulk. Larger DNS records may require TCP transfers instead of UDP ones. At the time of protocol design, the CERT RR was not widely deployed and could not be counted upon. Use of CERT records will be | investigated, and may result in a future revision of this document. | KX records are ideally suited for this use, but have not been | deployed in any known DNS implementations. 7.3 Use of FQDN IDs Unfortunately, not every administrator has control over the contents of the reverse-map. The only case where we can work around this is where the initiator (SG-A) has no suitable reverse map. In this case, the authorization record present in the reverse map of Alice may refer to a FQDN instead of an IP address. In this case, the client's TXT record gives the fully qualified domain name (FQDN) in place of its security gateway's IP address. The initiator should use the ID_FQDN ID-payload in phase 1. A forward lookup for a KEY record on the FQDN must yield the initiator's public key. This method can also be used when the external address of SG-A is dynamic. If SG-A is acting on behalf of Alice, then Alice must still delegate authority for SG-A to do so in her reverse map. When Alice is SG-A (i.e. Alice is acting as an end-node) then there is no need for |Richardson, et al. Expires July 1, 2002 [Page 24] |Internet-Draft opportunistic December 2001 this. See Figure 6 |Richardson, et al. Expires July 1, 2002 [Page 25] |Internet-Draft opportunistic December 2001 8. Network Address Translation interaction There are no fundamentally new issues for getting opportunistic encryption to work in the presence of network address translation. Rather there are just the regular IPsec issues with NAT traversal. There are several situations to consider for NAT: 8.1 Colocated NAT/NAPT If SG-A is also performing Network Address Translation on behalf of Alice, then the packet should be translated prior to being subjected to opportunistic encryption. This is in contrast to typical configured tunnel which often exist to bridge islands of private network address space. SG-A will use the translated source address for phase 2, and so SG-B will look that address up to confirm SG-A's authorization. In the case of NAT (1:1), the address space into which the translation is done MUST be globally unique, and so control over the reverse map is assumed to be a given. Placing of TXT records is possible. In the case of NAPT (m:1), the address will be SG-A. The ability to get KEY and TXT records in place will again depend upon whether or not there is administrative control over the reverse map. This is identical situations involving a single host acting on behalf of itself. FQDN style can be used to get around a lack of a reverse map for initiators only. 8.2 SG-A behind NAT/NAPT If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec NAT traversal rules would apply. In addition to the transport | problem which can be solved via proposals like [5], there is the issue of what phase 1 and phase 2 IDs to use. While FQDN could be used during phase 1 for SG-A. An appropriate ID for phase 2 permits SG-B to determine that SG-A was in fact authorized to speak for Alice. This is only possible if Alice actually has a public IP. It is a somewhat unusual case where a public network exists behind SG-A, while SG-A itself is behind a NAPT. This may occur with mobile networks of various kinds that occasionally wind up behind a NAPT. 8.3 Bob is behind a NAT/NAPT If Bob is behind a NAT (perhaps SG-B), then there is in fact no way |Richardson, et al. Expires July 1, 2002 [Page 26] |Internet-Draft opportunistic December 2001 for Alice to address a packet to Bob. Not only is opportunistic encryption impossible, but it is also impossible for Alice to initiate any communication to Bob. It may be possible for Bob to initiate in such a situation. |Richardson, et al. Expires July 1, 2002 [Page 27] |Internet-Draft opportunistic December 2001 9. Host implementations When Alice and SG-A are components of the same system, then this is considered to be a host implementation. The scenario remains unchanged with respect to packet sequence. Components marked Alice are simply the upper layers (TCP, UDP, the application), and SG-A is the IP layer. Note that tunnel mode is still recommended. As Alice/SG-A are acting on behalf of themselves, no TXT based delegation record is necessary for Alice. She can rely on a FQDN in a forward map. |Richardson, et al. Expires July 1, 2002 [Page 28] |Internet-Draft opportunistic December 2001 10. Multihoming If there are multiple paths between Alice and Bob (such as illustrated in the diagram with SG-D) then additional DNS records are required to establish authorization. In the diagram in Figure 1, Alice has two ways to exit her network: SG-A and SG-D. Previously SG-D has been ignored. Postulate that there are routers between Alice and her set of security gateways (denoted by the + signs and the marking of an autonomous system number for Alice's network). Packets may therefore travel to either SG-A or SG-D en route to Bob. As long as all network connections are in good order it does not matter how packets exit Alice's network. When they reach either security gateway, the security gateway will find the TXT delegation record in Bob's reverse map, and establish an SA with SG-B. SG-B has no problem establishing that either of SG-A or SG-D may speak for Alice, as Alice has published two equally weighted TXT delegation records: | --------------------------------------------------------------------- X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9== | Figure 7: Multiple gateway delegation example | --------------------------------------------------------------------- Alice's routers can now happily do any kind of load sharing that they might wish to do. SG-A and SG-D will both send packets addressed to Bob through their tunnel to SG-B. If Alice wishes to prefer one gateway over another, then Bob should, upon finding that it has connections to two gateways en route to Alice, prefer the one with the lower precedence. If the precendences are the same, then SG-B has a more difficult time. It must decide which of the two tunnels to use. SG-B has no information about which link is less loaded, nor which security gateway has more cryptographic resources available. SG-B in fact has no knowledge of whether both gateways are even reachable. The Public Internet's default free zone may well know a good route to Alice, but the packets that SG-B creates must be addressed to either |Richardson, et al. Expires July 1, 2002 [Page 29] |Internet-Draft opportunistic December 2001 | SG-A or SG-D; they can not be addressed to Alice directly. | There are a number of choices which SG-B may do: | 1. It can ignore the problem and round robin among the tunnels it | has. This will cause losses during times when one or the | other security gateway is unreachable. If this worries Alice, | she can change the weights in her TXT delegation records. | 2. It can always send to the gateway that it most recently | received from. This assumes that routing and reachability is | symmetrical. 3. It can listen to BGP information from the Internet to decide which system is currently up. This is clearly a much more complicated thing to do, but if SG-B is already doing this | because it is participating in the BGP peering system to | announce Bob, the results data may already be available to it. 4. It can refuse to negotiate the second tunnel. 5. It can silently replace the first tunnel with the second one, | while still being willing to accept packets from either SG-A | or SG-D. | These are decisions left to local policy. Note that even if SG-B has perfect knowledge about reachability of SG-A and SG-D, Alice may not be reachable from one or other of these security gateways due to internal reachability issues. FreeS/WAN implements option 5, but plans to implement option 2 in the future. |Richardson, et al. Expires July 1, 2002 [Page 30] |Internet-Draft opportunistic December 2001 11. Failure modes 11.1 DNS failures If a DNS server fails to respond, then it is a local policy decision | whether or not to permit communication in the clear. It should be | clear that mounting a denial of service attack on the DNS server responsible for a particular network's reverse map is an easy thing to do. Such an attack may cause all communication with that network to go in the clear. Please note that this is an active attack. At the same time, there are still a very large number of networks that do not have properly configured reverse maps. Further, the effect of the above denial of service attack, if the policy is not to communicate, is that the target network becomes isolated. This is why this decision MUST be a matter of local policy. 11.2 DNS configured, IKE failures In this situation, DNS records claim that opportunistic encryption should occur, but the target gateway either does not respond on port 500, or refuses the proposal. This may be due to a crash/reboot, due to misconfiguration, a firewall filtering port 500. The receipt of ICMP port, host or network unreachable messages should be taken as a sign that there is a potential problem, but MUST NOT cause communication to fail immediately. It is recommended that in these situations that a clear log be produced about the problem. A local policy should dictate if communication is then permitted in the clear at this point. 11.3 System reboots Tunnels sometimes go down because the other end crashes, or disconnects, or has a network link break, and there is no notice of this in the general case. (Even in the event of a crash and successful reboot, other SGs don't hear about it unless the rebooted SG has specific reason to talk to them immediately.) Over-quick response to temporary network out- ages is undesirable... but note that a tunnel can be torn down and then re-established without any user-visible effect except a pause in traffic, whereas if one end does reboot, the other end can't get packets to it at all (except via IKE) until the situation is noticed. So a bias toward quick response is appropriate, even at the cost of occasional false alarms. A mechanism for recover after reboot is not specified in this |Richardson, et al. Expires July 1, 2002 [Page 31] |Internet-Draft opportunistic December 2001 document, as it is a topic of current research. A deliberate shutdown should include an attempt to notify all other | SGs currently connected by phase 1 SAs, using Deletes, that communication is about to fail. (Again, these will be taken as teardowns; attempts by the other SGs to negotiate new tunnels as replacements should be ignored at this point.) And when possible, SGs should attempt to preserve information about currently-connected SGs in non-volatile storage, so that after a crash, an Initial-Contact can be sent to previous partners to indicate loss of all previ- ously-established connections. |Richardson, et al. Expires July 1, 2002 [Page 32] |Internet-Draft opportunistic December 2001 12. Unresolved issues 12.1 Control of reverse DNS The method of obtaining information is by reverse DNS lookup causes problems for people who can not control their reverse DNS bindings. This is an unresolved problem in this version, and is out of scope. |Richardson, et al. Expires July 1, 2002 [Page 33] |Internet-Draft opportunistic December 2001 13. Security Considerations 13.1 Configured vs Opportunistic Tunnels Configured tunnels are those which are setup using bilateral mechanisms: exchanging public keys (raw RSA, DSA, PKIX), pre-shared secrets, or by referencing keys that are in known places (distinguished name from LDAP, DNS). These keys are then used to configure a specific tunnel. A pre-configured tunnel may be on all the time, or may be keyed only when needed. The end points of the tunnel are not necessarily static: many mobile applications ("road warrior") are considered to be configured tunnels. The key consideration is that configured tunnels are assigned specific security properties. They may be trusted in different ways. This is usually related to exceptions to firewall rules, exceptions to NAT processing, and to bandwidth or other quality of service restrictions. | Opportunistic tunnels are not inherently trusted in anyway. They are | created without prior arrangement. As the two parties are strangers, | there MUST be no confusion of packets that arrive from opportunistic | peers and those that arrive from configured tunnels. A security | gateway MUST take care that an opportunistic peer can not impersonate | a configured peer. | It is recommended that an implementation MUST prevent opportunistic peer from impersonating another opportunistic peer. This is equivalent to inforcing ingress filtering of source addresses. An implementation suggestion is to logically treat opportunistically tunnel packets as if they arrive on a distinct logical interface from other configured tunnels. As the number of opportunistic tunnels that may be created automatically on a system is potentially very high, careful attention to scaling should be taken into account. | As with any IKE negotiation, opportunistic encryption cannot be | secure without authentication. Opportunistic encryption relies on | DNS for its authentication information and therefore cannot be fully | secure without a secure DNS. Without secure DNS, it can protect | against passive eavesdropping, but not against active man-in-the- | middle attacks. 13.2 Firewalls vs Opportunistic Tunnels Typical usage of per-packet access control lists is to implement |Richardson, et al. Expires July 1, 2002 [Page 34] |Internet-Draft opportunistic December 2001 various kinds of security gateways. These are typically called "firewalls". Typical usage of virtual private network (VPN) within a firewall is to bypass all or part of the access controls between two networks. Additional trust (as outlined in the previous section) is given to packets that arrive in the VPN. Packets that arrive via opportunistically configured tunnels MUST not be trusted. Any security policy that would apply to a packet arriving in the clear SHOULD also be applied to packets arriving opportunistically. 13.3 Denial of Service There are several different forms of denial of service which an implementor should concern themselves with. Most of these problems are shared with security gateways that have large numbers of mobile peers (road warriors). The design of ISAKMP/IKE, and its use of cookies defend against many kinds of denial of service. There is an assumption that if the phase 1 (ISAKMP) SA is authenticated, that it was worthwhile creating. Opportunism changes this assumption. As the gateway will communicate with anyone, it is possible to form phase 1 SAs with any machine on the Internet. |Richardson, et al. Expires July 1, 2002 [Page 35] |Internet-Draft opportunistic December 2001 14. IANA Considerations There are no known numbers which IANA will need to manage. |Richardson, et al. Expires July 1, 2002 [Page 36] |Internet-Draft opportunistic December 2001 References [1] Redelmeier, D. and H. Spencer, "Opportunistic Encryption", | paper http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/ | opportunism.spec, May 2001. | [2] IAB, IESG, Carpenter, B. and F. Baker, "IAB and IESG Statement | on Cryptographic Technology and the Internet", RFC 1984, August | 1996. | [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. | [4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. | [5] Huttunen, A. and W. Dixon, "UDP Encapsulation of IPsec Packets", ID internet-draft (draft-ietf-ipsec-udp-encaps-00), June 2001. | [6] Kivinen, T. and M. Kojo, "More MODP Diffie-Hellman groups for | IKE", ID internet-draft (draft-ietf-ipsec-ike-modp-groups-03), | November 2001. | [7] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. | [8] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993. | [9] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. | [10] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", RFC 2537, March 1999. | [11] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999. | [12] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. | [13] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. |Richardson, et al. Expires July 1, 2002 [Page 37] |Internet-Draft opportunistic December 2001 Authors' Addresses Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA EMail: mcr@sandelman.ottawa.on.ca URI: http://www.sandelman.ottawa.on.ca/ D. Hugh Redelmeier Mimosa Toronto, ON CA EMail: hugh@mimosa.com Henry Spencer SP Systems Box 280 Station A Toronto, ON M5W 1B2 Canada EMail: henry@spsystems.net |Richardson, et al. Expires July 1, 2002 [Page 38] |Internet-Draft opportunistic December 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. |Richardson, et al. Expires July 1, 2002 [Page 39]