Network Working Group M. Richardson Internet-Draft SSW |Expires: December 30, 2001 D. Redelmeier Mimosa H. Spencer spsystems | July 2001 A method for doing opportunistic encryption with IKE | draft-richardson-ipsec-opportunistic-01.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 December 30, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. |Richardson, et. al. Expires December 30, 2001 [Page 1] Internet-Draft opportunistic July 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. Project Goals and Requirements . . . . . . . . . . . . . . . 10 | 4. Brief overview of method used . . . . . . . . . . . . . . . 11 | 5. Detailed description of process . . . . . . . . . . . . . . 14 | 5.1 (5) IPsec packet interception . . . . . . . . . . . . . . . 14 | 5.2 (5B) DNS lookup for TXT record . . . . . . . . . . . . . . . 14 | 5.3 (5C) DNS returns TXT record(s) . . . . . . . . . . . . . . . 14 | 5.4 (5D) Initial IKE Main Mode Packet goes out . . . . . . . . . 15 | 5.5 (5E1) Message 2 of phase 1 exchange . . . . . . . . . . . . 15 | 5.6 (5E2) Message 3 of phase 1 exchange . . . . . . . . . . . . 15 | 5.7 (5F1) Responder lookup of initiator key . . . . . . . . . . 15 | 5.8 (5F2) DNS replies with public key of initiator . . . . . . . 15 | 5.9 (5G) IKE phase 2 . . . . . . . . . . . . . . . . . . . . . . 15 | 5.9.1 (5G1) Initiator proposes tunnel . . . . . . . . . . . . . . 15 | 5.9.2 (5G2) Responder determines initiator's authority . . . . . . 15 | 5.9.3 (5G3) DNS replies with TXT record . . . . . . . . . . . . . 16 | 5.9.4 (5G4) Responder agrees to proposal . . . . . . . . . . . . . 16 | 5.10 (6) IPsec succeeds, sets up tunnel for communication | between Alice and Bob . . . . . . . . . . . . . . . . . . . 16 | 5.11 (9) SG-B already has tunnel up with G1, uses it . . . . . . 16 | 6. Impacts on IKE . . . . . . . . . . . . . . . . . . . . . . . 17 | 6.1 ISAKMP/IKE protocol . . . . . . . . . . . . . . . . . . . . 17 | 6.2 Gateway discovery process . . . . . . . . . . . . . . . . . 17 | 6.3 Self identification . . . . . . . . . . . . . . . . . . . . 17 | 6.4 Public key Retrieval process . . . . . . . . . . . . . . . . 18 | 6.5 Interactions with DNSSEC . . . . . . . . . . . . . . . . . . 18 | 6.6 Interactions with COPS . . . . . . . . . . . . . . . . . . . 18 | 6.7 Recommended proposal types . . . . . . . . . . . . . . . . . 18 | 6.7.1 Phase 1 IDs . . . . . . . . . . . . . . . . . . . . . . . . 18 | 6.7.2 Phase 2 IDs . . . . . . . . . . . . . . . . . . . . . . . . 19 | 7. DNS issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 7.1 Use of KEY record . . . . . . . . . . . . . . . . . . . . . 20 | 7.2 Use of TXT record . . . . . . . . . . . . . . . . . . . . . 20 | 7.3 Use of FQDN IDs . . . . . . . . . . . . . . . . . . . . . . 21 | 7.4 Impact on DNS servers . . . . . . . . . . . . . . . . . . . 21 | 8. Network Address Translation interaction . . . . . . . . . . 22 | 8.1 Colocated NAT/NAPT . . . . . . . . . . . . . . . . . . . . . 22 | 8.2 SG-A behind NAT/NAPT . . . . . . . . . . . . . . . . . . . . 22 | 8.3 Bob is behind a NAT/NAPT . . . . . . . . . . . . . . . . . . 23 | 9. Host implementations . . . . . . . . . . . . . . . . . . . . 24 | 10. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . 25 |Richardson, et. al. Expires December 30, 2001 [Page 2] |Internet-Draft opportunistic July 2001 | 11. Performance Experiences . . . . . . . . . . . . . . . . . . 26 | 11.1 Introduced latency . . . . . . . . . . . . . . . . . . . . . 26 | 11.2 Cryptographic performance . . . . . . . . . . . . . . . . . 26 | 11.3 Phase 1 SA performance . . . . . . . . . . . . . . . . . . . 26 | 12. Unresolved issues . . . . . . . . . . . . . . . . . . . . . 27 | 13. Security Considerations . . . . . . . . . . . . . . . . . . 28 | 13.1 Configured vs Opportunistic Tunnels . . . . . . . . . . . . 28 | 13.2 Firewalls vs Opportunistic Tunnels . . . . . . . . . . . . . 28 | 13.3 Denial of Service . . . . . . . . . . . . . . . . . . . . . 28 | 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 | References . . . . . . . . . . . . . . . . . . . . . . . . . 30 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 | Full Copyright Statement . . . . . . . . . . . . . . . . . . 32 |Richardson, et. al. Expires December 30, 2001 [Page 3] Internet-Draft opportunistic July 2001 Abstract This document discusses a method used by the Linux FreeS/WAN project | to opportunistically encrypt traffic between peers without specific | pre-arrangement. It describes the infrastructure necessary to | support this configuration. Opportunistic Encryption (OE) provides | major simplifications of typical configurations, as it scales | linearly rather than quadratically in the number of systems involved. | There are naturally some risks, which are described. | This document is offered up as an Informational RFC. |Richardson, et. al. Expires December 30, 2001 [Page 4] Internet-Draft opportunistic July 2001 1. Introduction The Linux FreeS/WAN project started in 1996. Its goal was to secure | 5% of the Internet traffic against passive wire-tapping, increasing | over time to 80%. 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. This | project attempts to put this policy into practice by providing | practical means to implement them. | This idea does not originate with this project; lots of people have | been working on it for years. The encryption protocols for these | boxes are called IPsec (IP Security). They have been developed by | the IP Security Working Group of the Internet Engineering Task Force, | and became a standard in 1999. See RFC 2401 [2]. The project believes that these protocols are the best chance to do that, because they can be deployed very easily, without changing hardware or software or retraining of users. | 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 | 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 |Richardson, et. al. Expires December 30, 2001 [Page 5] |Internet-Draft opportunistic July 2001 | 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. |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 | 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. |Richardson, et. al. Expires December 30, 2001 [Page 6] |Internet-Draft opportunistic July 2001 | 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 [1] |Richardson, et. al. Expires December 30, 2001 [Page 7] Internet-Draft opportunistic July 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 In this diagram, there are four end-nodes: A, B, C and D. There are | four 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 and G3/C are part of two | independent organizations. Nodes Q and R are nodes that are on the | Internet. PI is the Public Internet ("The Wild"). | When the actual IP address is needed to be referred to, this is done | by the notation: X{1}.X{2}.X{3}.X{4} where X may be A,B,C,D,SG-A,SG- | B,SG-D. |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. Bob: node [B] in the diagram. Carol: node [C] in the diagram. Dave: node [D] in the diagram. | - 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 |Richardson, et. al. Expires December 30, 2001 [Page 8] Internet-Draft opportunistic July 2001 | 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 phase 2 SA an IPsec security association | tunnel another term for a set of phase 2 SA | NAT Network Address Translation (see [8] | NAPT Network Address and Port Translation (see [8] | anonymous encryption: | opportunistic encryption: |Richardson, et. al. Expires December 30, 2001 [Page 9] Internet-Draft opportunistic July 2001 3. Project Goals and Requirements To be inserted. |Richardson, et. al. Expires December 30, 2001 [Page 10] Internet-Draft opportunistic July 2001 4. Brief overview of method used Alice Gate1 DNS Gate2 Bob (1) ------(2)--------------> <-----(3)--------------- (4)----(5)----->----------(6)------>------(7)-----> <----(10)-----<----------(9)------<------(8)------ | (11)----------->----------(12)----->--------------> | <-------------<-------------------<--------------- 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 December 30, 2001 [Page 11] Internet-Draft opportunistic July 2001 Alice SGate1 DNS SGate2 Bob (1) ------(2)--------------> <-----(3)--------------- (4)----(5)----->+ ----(5B)-> <---(5C)-- -------------(5D)---> <------------(5E1)--- #############(5E2)##> <############(5E3)### <----(5F1)-- -----(5F2)-> #############(5G1)##> | <----(5G2)-- | -----(5G3)-> | <############(5G4)### ============(6)====>------(7)-----> <-----(10)----<==========(9)======<------(8)------ (11)----------->==========(12)=====>--------------> <-------------<===================<--------------- In the presence of properly configured opportunistic encryptors, the event list is extended. (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 | (5C) DNS returns TXT record(s) | (5D) Initial IKE Main Mode Packet goes out (5E) IKE ISAKMP phase succeeds | (5F) SG-B asks the DNS for TXT record to prove SG-A agent for Alice | (5G) IKE phase 2 negotiation (5H) IPsec succeeds, sets up tunnel for communication between Alice |Richardson, et. al. Expires December 30, 2001 [Page 12] Internet-Draft opportunistic July 2001 | and Bob | (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 December 30, 2001 [Page 13] Internet-Draft opportunistic July 2001 5. Detailed description of process For the purposes of this section, we will describe on the changes that occur between Figure 2 and . This means time points 5, 6, 7, 9 and 10. |5.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 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. |5.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 the usual way. The lookup requests TXT records. These | are interpreted as described in Section 7.2. | In this context, the returned record might contain: | X-IPsec-Server(10)=SG-B{1}.SG-B{2}.SG-B{3}.SG-B{4} AQMM...3s1Q== | with SG-B's IP address and public key listed. |5.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. |Richardson, et. al. Expires December 30, 2001 [Page 14] Internet-Draft opportunistic July 2001 |5.4 (5D) Initial IKE Main Mode Packet goes out | SG-A sends the initial ISAKMP message. |5.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. |5.6 (5E2) Message 3 of phase 1 exchange | SG-A uses the phase 1 SA to send its identity. The choice of | identity is discussed in Section 6.7.1. |5.7 (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 SG-A{4}.SG- | A{3}.SG-A{2}.SG-A{1}.in-addr.arpa. The resulting public key is used | to authenticate the initiator. See Section 7.1 for further details. |5.8 (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 | 7.2. |5.9 (5G) IKE phase 2 |5.9.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. |5.9.2 (5G2) 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 | requesting a TXT resource record for A{4}.A{3}.A{2}.A{1}.in-addr.arpa | as was done by SG-A for Bob in step 5B. |Richardson, et. al. Expires December 30, 2001 [Page 15] |Internet-Draft opportunistic July 2001 |5.9.3 (5G3) DNS replies with TXT record | The returned key and IP address should match that of SG-A. |5.9.4 (5G4) 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. |5.10 (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). |5.11 (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 December 30, 2001 [Page 16] Internet-Draft opportunistic July 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. |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 December 30, 2001 [Page 17] |Internet-Draft opportunistic July 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. |6.6 Interactions with COPS | At this time there is no experience with implementations that | interact with COPS Policy Decision Points (PDP) [7]. It is suggested | that it may be appropriate for many of the policy and discovery | mechanisms outlined here to be done by a PDP. In this context, the | IKE daemon present in the Policy Enforcement Point (PEP) may not need | any modifications. |6.7 Recommended proposal types |6.7.1 Phase 1 IDs | Main mode is recommended. | The second oakley (1024) or group 5 (1536) group is recommended. | For Phase 1, a proposal of 3DES-CBC with MD5 authentication should be | used. | SG-A should use an ID_IPV4_ADDR, of the external interface of SG-A | for phase 1. The authentication method should be RSA Public key | signatures. | The RSA key for SG-A should be placed into a DNS KEY record at SG- | A{4}.SG-A{3}.SG-A{2}.SG-A{1}.in-addr.arpa. |Richardson, et. al. Expires December 30, 2001 [Page 18] |Internet-Draft opportunistic July 2001 |6.7.2 Phase 2 IDs | SG-A should propose a tunnel between Alice and Bob, using 3DES-CBC | mode, MD5 or SHA1 authentication, and using Perfect Forward Secrecy. | 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 December 30, 2001 [Page 19] |Internet-Draft opportunistic July 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 [5]. | 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 [6] |7.2 Use of TXT 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, although this is presently not deployed yet. | 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 resource record is expected to include a record that follows the | following syntax, as suggested in [4]: | X-IPsec-Server(P)=A.B.C.D KEY | 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. |Richardson, et. al. Expires December 30, 2001 [Page 20] |Internet-Draft opportunistic July 2001 | KEY: is the encoded RSA Public key of the Security Gateway. This is | provided here to avoid a second DNS lookup. |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. | Note that the client's reverse map must still exist. |7.4 Impact on DNS servers |Richardson, et. al. Expires December 30, 2001 [Page 21] Internet-Draft opportunistic July 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 issues. 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, the reverse map MUST be under SG-A's | administrator's control, so placing of TXT records will be possible. | In the case of NAPT, 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. While FQDN | style can be used to get around part of the problem, the | authorization for the FQDN to act upon SG-A's behalf can not be | established, and so the typical residential case of NAPT being used | to connect a household network can not be accommodated. | Should the appropriate administrative records be possible to provide, | it will generally be impossible to provide for separate tunnels for | Alice vs D that transit through SG-A. |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 [3], 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 may not | exist. Without this, there is nothing which would permit SG-B to | determine that SG-A was in fact authorized to speak for Alice. | There is an unusual case where a public network exists behind SG-A, | while SG-A itself is behind a NAT. This public network may in fact | not be routed publically, but as it is unique, the reverse map may be | consulted to provide appropriate authorization for SG-A. |Richardson, et. al. Expires December 30, 2001 [Page 22] |Internet-Draft opportunistic July 2001 |8.3 Bob is behind a NAT/NAPT | If Bob is behind a NAT (perhaps SG-B), then there is in fact no way | for Alice to address a packet to Bob. Not only is opportunistic | encryption impossible, but it is also impossible for Alice to | initiate any communication to Bob. It may be possible, if Alice has | a public address, for Bob to initiate. | Opportunistic encryption is therefore not generally feasible from | behind a NAT/NAPT. |Richardson, et. al. Expires December 30, 2001 [Page 23] |Internet-Draft opportunistic July 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 situation remains | unchanged. | 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. |Richardson, et. al. Expires December 30, 2001 [Page 24] Internet-Draft opportunistic July 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. | example to be provided. |Richardson, et. al. Expires December 30, 2001 [Page 25] |Internet-Draft opportunistic July 2001 |11. Performance Experiences |11.1 Introduced latency |11.2 Cryptographic performance |11.3 Phase 1 SA performance |Richardson, et. al. Expires December 30, 2001 [Page 26] Internet-Draft opportunistic July 2001 |12. Unresolved issues |Richardson, et. al. Expires December 30, 2001 [Page 27] Internet-Draft opportunistic July 2001 |13. Security Considerations |13.1 Configured vs Opportunistic Tunnels |13.2 Firewalls vs Opportunistic Tunnels |13.3 Denial of Service |Richardson, et. al. Expires December 30, 2001 [Page 28] Internet-Draft opportunistic July 2001 |14. IANA Considerations |Richardson, et. al. Expires December 30, 2001 [Page 29] Internet-Draft opportunistic July 2001 References | [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | Levels", BCP 14, RFC 2119, March 1997. | [2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. | [3] Huttunen, A. and W. Dixon, "UDP Encapsulation of IPsec Packets", | ID internet-draft (draft-ietf-ipsec-udp-encaps-00), June 2001. | [4] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary | String Attributes", RFC 1464, May 1993. | [5] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. | [6] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name System | (DNS)", RFC 2537, March 1999. | [7] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. | Sastry, "The COPS (Common Open Policy Service) Protocol", RFC | 2748, January 2000. | [8] Srisuresh, P. and M. Holdrege, "IP Network Address Translator | (NAT) Terminology and Considerations", RFC 2663, August 1999. Authors' Addresses Michael C. Richardson Sandelman Software Works 152 Rochester Street Ottawa, ON K1R 7M4 CA EMail: mcr@sandelman.ottawa.on.ca URI: http://www.sandelman.ottawa.on.ca/ D. Hugh Redelmeier Mimosa Somewhere Toronto, ON CA EMail: hugh@mimosa.com URI: http://www.sandelman.ottawa.on.ca/ |Richardson, et. al. Expires December 30, 2001 [Page 30] |Internet-Draft opportunistic July 2001 Henry Spencer SP Systems Box 280 Station A Toronto, ON M5W 1B2 Canada EMail: henry@spsystems.net |Richardson, et. al. Expires December 30, 2001 [Page 31] Internet-Draft opportunistic July 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 December 30, 2001 [Page 32]