Opportunistic Encryption Henry Spencer D. Hugh Redelmeier henry@spsystems.net hugh@mimosa.com Linux FreeS/WAN Project Opportunistic encryption permits secure (encrypted, authenticated) communication via IPsec without connection-by-connection prearrangement, either explicitly between hosts (when the hosts are capable of it) or transparently via packet- intercepting security gateways. It uses DNS records (authenticated with DNSSEC) to provide the necessary information for gateway discovery and gateway authentication, and constrains negotiation enough to guarantee success. Substantive changes since draft 3: write off inverse queries as a lost cause; use Invalid-SPI rather than Delete as notification of unknown SA; minor wording improvements and clarifications. This document takes over from the older ``Imple- menting Opportunistic Encryption'' document. 1. Introduction A major goal of the FreeS/WAN project is opportunistic encryption: a (security) gateway intercepts an outgoing packet aimed at a remote host, and quickly attempts to nego- tiate an IPsec tunnel to that host's security gateway. If the attempt succeeds, traffic can then be secure, transpar- ently (without changes to the host software). If the attempt fails, the packet (or a retry thereof) passes through in clear or is dropped, depending on local policy. Prearranged tunnels bypass the packet interception etc., so static VPNs can coexist with opportunistic encryption. This generalizes trivially to the end-to-end case: host and security gateway simply are one and the same. Some opti- mizations are possible in that case, but the basic scheme need not change. The objectives for security systems need to be explicitly stated. Opportunistic encryption is meant to achieve secure communication, without prearrangement of the individual con- nection (although some prearrangement on a per-host basis is Draft 4 3 May 2001 1 Opportunistic Encryption required), between any two hosts which implement the proto- col (and, if they act as security gateways, between hosts behind them). Here ``secure'' means strong encryption and authentication of packets, with authentication of partici- pants--to prevent man-in-the-middle and impersonation attacks--dependent on several factors. The biggest factor is the authentication of DNS records, via DNSSEC or equiva- lent means. A lesser factor is which exact variant of the setup procedure (see section 2.2) is used, because there is a tradeoff between strong authentication of the other end and ability to negotiate opportunistic encryption with hosts which have limited or no control of their reverse-map DNS records: without reverse-map information, we can verify that the host has the right to use a particular FQDN (Fully Qual- ified Domain Name), but not whether that FQDN is authorized to use that IP address. Local policy must decide whether authentication or connectivity has higher priority. Apart from careful attention to detail in various areas, there are three crucial design problems for opportunistic encryption. It needs a way to quickly identify the remote host's security gateway. It needs a way to quickly obtain an authentication key for the security gateway. And the numerous options which can be specified with IKE must be constrained sufficiently that two independent implementa- tions are guaranteed to reach agreement, without any explicit prearrangement or preliminary negotiation. The first two problems are solved using DNS, with DNSSEC ensur- ing that the data obtained is reliable; the third is solved by specifying a minimum standard which must be supported. A note on philosophy: we have deliberately avoided providing six different ways to do each job, in favor of specifying one good one. Choices are provided only when they appear to be necessary, or at least important. A note on terminology: to avoid constant circumlocutions, an ISAKMP/IKE SA, possibly recreated occasionally by rekeying, will be referred to as a ``keying channel'', and a set of IPsec SAs providing bidirectional communication between two IPsec hosts, possibly recreated occasionally by rekeying, will be referred to as a ``tunnel'' (it could conceivably use transport mode in the host-to-host case, but we advocate using tunnel mode even there). The word ``connection'' is here used in a more generic sense. The word ``lifetime'' will be avoided in favor of ``rekeying interval'', since many of the connections will have useful lives far shorter than any reasonable rekeying interval, and hence the two concepts must be separated. A note on document structure: Discussions of why things were done a particular way, or not done a particular way, are broken out in paragraphs headed ``Rationale:'' (to preserve the flow of the text, many such paragraphs are deferred to Draft 4 3 May 2001 2 Opportunistic Encryption the ends of sections). Paragraphs headed ``Ahem:'' are dis- cussions of where the problem is being made significantly harder by problems elsewhere, and how that might be cor- rected. Some meta-comments are enclosed in []. Rationale: The motive is to get the Internet encrypted. That requires encryption without connection-by-connection prearrangement: a system must be able to reliably negotiate an encrypted, authenticated connection with a total stranger. While end-to-end encryption is preferable, doing opportunistic encryption in security gateways gives enormous leverage for quick deployment of this technology, in a world where end-host software is often primitive, rigid, and out- dated. Rationale: Speed is of the essence in tunnel setup: a con- nection-establishment delay longer than about 10 seconds begins to cause problems for users and applications. Thus the emphasis on rapidity in gateway discovery and key fetch- ing. Ahem: Host-to-host opportunistic encryption would be utterly trivial if a fast public-key encryption/signature algorithm was available. You would do a reverse lookup on the desti- nation address to obtain a public key for that address, and simply encrypt all packets going to it with that key, sign- ing them with your own private key. Alas, this is impracti- cal with current CPU speeds and current algorithms (although as noted later, it might be of some use for limited pur- poses). Nevertheless, it is a useful model. 2. Connection Setup For purposes of discussion, the network is taken to look like this: Source----Initiator----...----Responder----Destination The intercepted packet comes from the Source, bound for the Destination, and is intercepted at the Initiator. The Ini- tiator communicates over the insecure Internet to the Responder. The Source and the Initiator might be the same host, or the Source might be an end-user host and the Ini- tiator a security gateway (SG). Likewise for the Responder and the Destination. Given an intercepted packet, whose useful information (for our purposes) is essentially only the Destination's IP address, the Initiator must quickly determine the Responder (the Destination's SG) and fetch everything needed to authenticate it. The Responder must do likewise for the Initiator. Both must eventually also confirm that the other is authorized to act on behalf of the client host behind it (if any). Draft 4 3 May 2001 3 Opportunistic Encryption An important subtlety here is that if the alternative to an IPsec tunnel is plaintext transmission, negative results must be obtained quickly. That is, the decision that no tunnel can be established must also be made rapidly. 2.1. Packet Interception Interception of outgoing packets is relatively straightfor- ward in principle. It is preferable to put the intercepted packet on hold rather than dropping it, since higher-level retries are not necessarily well-timed. There is a problem of hosts and applications retrying during negotiations. ARP implementations, which face the same problem, use the approach of keeping the most recent packet for an as-yet- unresolved address, and throwing away older ones. (Incre- menting of request numbers etc. means that replies to older ones may no longer be accepted.) Is it worth intercepting incoming packets, from the outside world, and attempting tunnel setup based on them? No, unless and until a way can be devised to initiate oppor- tunistic encryption to a non-opportunistic responder, because if the other end has not initiated tunnel setup itself, it will not be prepared to do so at our request. Rationale: Note, however, that most incoming packets will promptly be followed by an outgoing packet in response! Conceivably it might be useful to start early stages of negotiation, at least as far as looking up information, in response to an incoming packet. Rationale: If a plaintext incoming packet indicates that the other end is not prepared to do opportunistic encryption, it might seem that this fact should be noted, to avoid consum- ing resources and delaying traffic in an attempt at oppor- tunistic setup which is doomed to fail. However, this would be a major security hole, since the plaintext packet is not authenticated; see section 2.5. 2.2. Algorithm For clarity, the following defers most discussion of error handling to the end. Step 1. Initiator does a DNS reverse lookup on the Destina- tion address, asking not for the usual PTR records, but for TXT records. Meanwhile, Initiator also sends a ping to the Destination, to cause any other dynamic setup actions to start happening. (Ping replies are disregarded; the host might not be reachable with plaintext pings.) Step 2A. If at least one suitable TXT record (see section 2.3) comes back, each contains a potential Draft 4 3 May 2001 4 Opportunistic Encryption Responder's IP address and that Responder's public key (or where to find it). Initiator picks one TXT record, based on priority (see 2.3), thus picking a Responder. If there was no public key in the TXT record, the Initiator also starts a DNS lookup (as specified by the TXT record) to get KEY records. Step 2B. If no suitable TXT record is available, and policy permits, Initiator designates the Destination itself as the Responder (see section 2.4). If pol- icy does not permit, or the Destination is unre- sponsive to the negotiation, then opportunistic encryption is not possible, and Initiator gives up (see section 2.5). Step 3. If there already is a keying channel to the Respon- der's IP address, the Initiator uses the existing keying channel; skip to step 10. Otherwise, the Initiator starts an IKE Phase 1 negotiation (see section 2.7 for details) with the Responder. The address family of the Responder's IP address dic- tates whether the keying channel and the outside of the tunnel should be IPv4 or IPv6. Step 4. Responder gets the first IKE message, and responds. It also starts a DNS reverse lookup on the Initia- tor's IP address, for KEY records, on speculation. Step 5. Initiator gets Responder's reply, and sends first message of IKE's D-H exchange (see 2.4). Step 6. Responder gets Initiator's D-H message, and responds with a matching one. Step 7. Initiator gets Responder's D-H message; encryption is now established, authentication remains to be done. Initiator sends IKE authentication message, with an FQDN identity if a reverse lookup on its address will not yield a suitable KEY record. (Note, an FQDN need not actually correspond to a host--e.g., the DNS data for it need not include an A record.) Step 8. Responder gets Initiator's authentication message. If there is no identity included, Responder waits for step 4's speculative DNS lookup to finish; it should yield a suitable KEY record (see 2.3). If there is an FQDN identity, responder discards any data obtained from step 4's DNS lookup; does a for- ward lookup on the FQDN, for a KEY record; waits for that lookup to return; it should yield a suit- able KEY record. Either way, Responder uses the KEY data to verify the message's hash. Responder replies with an authentication message, with an Draft 4 3 May 2001 5 Opportunistic Encryption FQDN identity if a reverse lookup on its address will not yield a suitable KEY record. Step 9A. (If step 2A was used.) The Initiator gets the Responder's authentication message. Step 2A has provided a key (from the TXT record or via DNS lookup). Verify message's hash. Encrypted and authenticated keying channel established, man-in- middle attack precluded. Step 9B. (If step 2B was used.) The Initiator gets the Responder's authentication message, which must con- tain an FQDN identity (if the Responder can't put a TXT in his reverse map he presumably can't do a KEY either). Do forward lookup on the FQDN, get suit- able KEY record, verify hash. Encrypted keying channel established, man-in-middle attack pre- cluded, but authentication weak (see 2.4). Step 10. Initiator initiates IKE Phase 2 negotiation (see 2.7) to establish tunnel, specifying Source and Destination identities as IP addresses (see 2.6). The address family of those addresses also deter- mines whether the inside of the tunnel should be IPv4 or IPv6. Step 11. Responder gets first Phase 2 message. Now the Responder finally knows what's going on! Unless the specified Source is identical to the Initiator, Responder initiates DNS reverse lookup on Source IP address, for TXT records; waits for result; gets suitable TXT record(s) (see 2.3), which should con- tain either the Initiator's IP address or an FQDN identity identical to that supplied by the Initia- tor in step 7. This verifies that the Initiator is authorized to act as SG for the Source. Responder replies with second Phase 2 message, selecting acceptable details (see 2.7), and establishes tun- nel. Step 12. Initiator gets second Phase 2 message, establishes tunnel (if he didn't already), and releases the intercepted packet into it, finally. Step 13. Communication proceeds. See section 3 for what happens later. As additional information becomes available, notably in steps 1, 2, 4, 8, 9, 11, and 12, there is always a possibil- ity that local policy (e.g., access limitations) might pre- vent further progress. Whenever possible, at least attempt to inform the other end of this. Draft 4 3 May 2001 6 Opportunistic Encryption At any time, there is a possibility of the negotiation fail- ing due to unexpected responses, e.g. the Responder not responding at all or rejecting all Initiator's proposals. If multiple SGs were found as possible Responders, the Ini- tiator should try at least one more before giving up. The number tried should be influenced by what the alternative is: if the traffic will otherwise be discarded, trying the full list is probably appropriate, while if the alternative is plaintext transmission, it might be based on how long the tries are taking. The Initiator should try as many as it reasonably can, ideally all of them. There is a sticky problem with timeouts. If the Responder is down or otherwise inaccessible, in the worst case we won't hear about this except by not getting responses. Some other, more pathological or even evil, failure cases can have the same result. The problem is that in the case where plaintext is permitted, we want to decide whether a tunnel is possible quickly. There is no good solution to this, alas; we just have to take the time and do it right. (Pass- ing plaintext meanwhile looks attractive at first glance... but exposing the first few seconds of a connection is often almost as bad as exposing the whole thing. Worse, if the user checks the status of the connection, after that brief window it looks secure!) The flip side of waiting for a timeout is that all other forms of feedback, e.g. ``host not reachable'', arguably should be ignored, because in the absence of authenticated ICMP, you cannot trust them! Rationale: An alternative, sometimes suggested, to the use of explicit DNS records for SG discovery is to directly attempt IKE negotiation with the destination host, and assume that any relevant SG will be on the packet path, will intercept the IKE packets, and will impersonate the destina- tion host for the IKE negotiation. This is superficially attractive but is a very bad idea. It assumes that routing is stable throughout negotiation, that the SG is on the plaintext-packets path, and that the destination host is routable (yes, it is possible to have (private) DNS data for an unroutable host). Playing extra games in the plaintext- packet path hurts performance and can be expected to be unpopular. Various difficulties ensue when there are multi- ple SGs along the path (there is already bad experience with this, in RSVP), and the presence of even one can make it impossible to do IKE direct to the host when that is what's wanted. Worst of all, such impersonation breaks the IP net- work model badly, making problems difficult to diagnose and impossible to work around (and there is already bad experi- ence with this, in areas like web caching). Rationale: (Step 1.) Dynamic setup actions might include establishment of demand-dialed links. These might be Draft 4 3 May 2001 7 Opportunistic Encryption present anywhere along the path, so one cannot rely on out- of-band communication at the Initiator to trigger them. Hence the ping. Rationale: (Step 2.) In many cases, the IP address on the intercepted packet will be the result of a name lookup just done. Inverse queries, an obscure DNS feature from the dis- tant past, in theory can be used to ask a DNS server to reverse that lookup, giving the name that produced the address. This is not the same as a reverse lookup, and the difference can matter a great deal in cases where a host does not control its reverse map (e.g., when the host's IP address is dynamically assigned). Unfortunately, inverse queries were never widely implemented and are now considered obsolete. Phooey. Ahem: Support for a small subset of this admittedly-obscure feature would be useful. Unfortunately, it seems unlikely. Rationale: (Step 3.) Using only IP addresses to decide whether there is already a relevant keying channel avoids some difficult problems. In particular, it might seem that this should be based on identities, but those are not known until very late in IKE Phase 1 negotiations. Rationale: (Step 4.) The DNS lookup is done on speculation because the data will probably be useful and the lookup can be done in parallel with IKE activity, potentially speeding things up. Rationale: (Steps 7 and 8.) If an SG does not control its reverse map, there is no way it can prove its right to use an IP address, but it can nevertheless supply both an iden- tity (as an FQDN) and proof of its right to use that iden- tity. This is somewhat better than nothing, and may be quite useful if the SG is representing a client host which can prove its right to its IP address. (For example, a fixed-address subnet might live behind an SG with a dynami- cally-assigned address; such an SG has to be the Initiator, not the Responder, so the subnet's TXT records can contain FQDN identities, but with that restriction, this works.) It might sound like this would permit some man-in-the-middle attacks in important cases like Road Warrior, but the RW can still do full authentication of the home base, so a man in the middle cannot successfully impersonate home base, and the D-H exchange doesn't work unless the man in the middle impersonates both ends. Rationale: (Steps 7 and 8.) Another situation where proof of the right to use an identity can be very useful is when access is deliberately limited. While opportunistic encryp- tion is intended as a general-purpose connection mechanism between strangers, it may well be convenient for prearranged connections to use the same mechanism. Draft 4 3 May 2001 8 Opportunistic Encryption Rationale: (Steps 7 and 8.) FQDNs as identities are avoided where possible, since they can involve synchronous DNS lookups. Rationale: (Step 11.) Note that only here, in Phase 2, does the Responder actually learn who the Source and Destination hosts are. This unfortunately demands a synchronous DNS lookup to verify that the Initiator is authorized to repre- sent the Source, unless they are one and the same. This and the initial TXT lookup are the only synchronous DNS lookups absolutely required by the algorithm, and they appear to be unavoidable. Rationale: While it might seem unlikely that a refusal to cooperate from one SG could be remedied by trying another-- presumably they all use the same policies--it's conceivable that one might be misconfigured. Preferably they should all be tried, but it may be necessary to set some limits on this if alternatives exist. 2.3. DNS Records Gateway discovery and key lookup are based on TXT and KEY DNS records. The TXT record specifies IP address or other identity of a host's SG, and possibly supplies its public key as well, while the KEY record supplies public keys not found in TXT records. 2.3.1. TXT Opportunistic-encryption SG discovery uses TXT records with the content: X-IPsec-Gateway(nnn)=iii kkk following RFC 1464 attribute/value notation. Records which do not contain an ``='', or which do not have exactly the specified form to the left of it, are ignored. (Near misses perhaps should be reported.) The nnn is an unsigned integer which will fit in 16 bits, specifying an MX-style preference (lower number = stronger preference) to control the order in which multiple SGs are tried. If there are ties, pick one, randomly enough that the choice will probably be different each time. The pref- erence field is not optional; use ``0'' if there is no mean- ingful preference ordering. The iii part identifies the SG. Normally this is a dotted- decimal IPv4 address or a colon-hex IPv6 address. The sole exception is if the SG has no fixed address (see 2.4) but the host(s) behind it do, in which case iii is of the form ``@fqdn'', where fqdn is the FQDN that the SG will use to identify itself (in step 7 of section 2.2); such a record Draft 4 3 May 2001 9 Opportunistic Encryption cannot be used for SG discovery by an Initiator, but can be used for SG verification (step 11 of 2.2) by a Responder. The kkk part is optional. If it is present, it is an RSA- MD5 public key in base-64 notation, as in the text form of an RFC 2535 KEY record. If it is not present, this speci- fies that the public key can be found in a KEY record located based on the SG's identification: if iii is an IP address, do a reverse lookup on that address, else do a for- ward lookup on the FQDN. Rationale: While it is unusual for a reverse lookup to go for records other than PTR records (or possibly CNAME records, for RFC 2317 classless delegation), there's no rea- son why it can't. The TXT record is a temporary stand-in for (we hope, someday) a new DNS record for SG identifica- tion and keying. Keeping the setup process fast requires minimizing the number of DNS lookups, hence the desire to put all the information in one place. Rationale: The use of RFC 1464 notation avoids collisions with other uses of TXT records. The ``X-'' in the attribute name indicates that this format is tentative and experimen- tal; this design will probably need modification after ini- tial experiments. The format is chosen with an eye on even- tual binary encoding. Note, in particular, that the TXT record normally contains the address of the SG, not (repeat, not) its name. Name-to-address conversion is the job of whatever generates the TXT record, which is expected to be a program, not a human--this is conceptually a binary record, temporarily using a text encoding. The ``@fqdn'' form of the SG identity is for specialized uses and is never mapped to an address. Ahem: A DNS TXT record contains one or more character strings, but RFC 1035 does not describe exactly how a multi- string TXT record is interpreted. This is relevant because a string can be at most 255 characters, and public keys can exceed this. Empirically, the standard pattern is that each string which is both less than 255 characters and not the final string of the record should have a blank appended to it, and the strings of the record should then be concate- nated. (This observation is based on how BIND 8 transforms a TXT record from text to DNS binary.) 2.3.2. KEY An opportunistic-encryption KEY record is an Authentication- permitted, Entity (host), non-Signatory, IPsec, RSA/MD5 record (that is, its first four bytes are 0x42000401), as per RFCs 2535 and 2537. KEY records with other flags, pro- tocol, or algorithm values are ignored. Draft 4 3 May 2001 10 Opportunistic Encryption Rationale: Unfortunately, the public key has to be associ- ated with the SG, not the client host behind it. The Responder does not know which client it is supposed to be representing, or which client the Initiator is representing, until far too late. Ahem: Per-client keys would reduce vulnerability to key com- promise, and simplify key changes, but they would require changes to IKE Phase 1, to separately identify the SG and its initial client(s). (At present, the client identities are not known to the Responder until IKE Phase 2.) While the current IKE standard does not actually specify (!) who is being identified by identity payloads, the overwhelming consensus is that they identify the SG, and as seen earlier, this has important uses. 2.3.3. Summary For reference, the minimum set of DNS records needed to make this all work is either: 1. TXT in Destination reverse map, identifying Responder and providing public key. 2. KEY in Initiator reverse map, providing public key. 3. TXT in Source reverse map, verifying relationship to Initiator. or: 1. TXT in Destination reverse map, identifying Responder. 2. KEY in Responder reverse map, providing public key. 3. KEY in Initiator reverse map, providing public key. 4. TXT in Source reverse map, verifying relationship to Initiator. Slight complications ensue for dynamic addresses, lack of control over reverse maps, etc. 2.3.4. Implementation In the long run, we need either a tree of trust or a web of trust, so we can trust our DNS data. The obvious approach for DNS is a tree of trust, but there are various practical problems with running all of this through the root servers, and a web of trust is arguably more robust anyway. This is logically independent of opportunistic encryption, and a separate design proposal will be prepared. Draft 4 3 May 2001 11 Opportunistic Encryption Interim stages of implementation of this will require a bit of thought. Notably, we need some way of dealing with the lack of fully signed DNSSEC records right away. Without user interaction, probably the best we can do is to remember the results of old fetches, compare them to the results of new fetches, and complain and disbelieve all of it if there's a mismatch. This does mean that somebody who gets fake data into our very first fetch will fool us, at least for a while, but that seems an acceptable tradeoff. (Obvi- ously there needs to be a way to manually flush the remem- bered results for a specific host, to permit deliberate changes.) 2.4. Responders Without Credentials In cases where the Destination simply does not control its DNS reverse-map entries, there is no verifiable way to determine a suitable SG. This does not make communication utterly impossible, though. Simply attempting negotiation directly with the host is a last resort. (An aggressive implementation might wish to attempt it in parallel, rather than waiting until other options are known to be unavailable.) In particular, in many cases involving dynamic addresses, it will work. It has the disadvantage of delaying the discovery that oppor- tunistic encryption is entirely impossible, but the case seems common enough to justify the overhead. However, there are policy issues here either way, because it is possible to impersonate such a host. The host can supply an FQDN identity and verify its right to use that identity, but except by prearrangement, there is no way to verify that the FQDN is the right one for that IP address. (The data from forward lookups may be controlled by people who do not own the address, so it cannot be trusted.) The encryption is still solid, though, so in many cases this may be useful. 2.5. Failure of Opportunism When there is no way to do opportunistic encryption, a pol- icy issue arises: whether to put in a bypass (which allows plaintext traffic through) or a block (which discards it, perhaps with notification back to the sender). The choice is very much a matter of local policy, and may depend on details such as the higher-level protocol being used. For example, an SG might well permit plaintext HTTP but forbid plaintext Telnet, in which case both a block and a bypass would be set up if opportunistic encryption failed. A bypass/block must, in practice, be treated much like an IPsec tunnel. It should persist for a while, so that high- overhead processing doesn't have to be done for every packet, but should go away eventually to return resources. Draft 4 3 May 2001 12 Opportunistic Encryption It may be simplest to treat it as a degenerate tunnel. It should have a relatively long lifetime (say 6h) to keep the frequency of negotiation attempts down, except in the case where the other SG simply did not respond to IKE packets, where the lifetime should be short (say 10min) because the other SG is presumably down and might come back up again. (Cases where the other SG responded to IKE with unauthenti- cated error reports like ``port unreachable'' are border- line, and might deserve to be treated as an intermediate case: while such reports cannot be trusted unreservedly, in the absence of any other response, they do give some reason to suspect that the other SG is unable or unwilling to par- ticipate in opportunistic encryption.) As noted in section 2.1, one might think that arrival of a plaintext incoming packet should cause a bypass/block to be set up for its source host: such a packet is almost always followed by an outgoing reply packet; the incoming packet is clear evidence that opportunistic encryption is not avail- able at the other end; attempting it will waste resources and delay traffic to no good purpose. Unfortunately, this means that anyone out on the Internet who can forge a source address can prevent encrypted communication! Since their source addresses are not authenticated, plaintext packets cannot be taken as evidence of anything, except perhaps that communication from that host is likely to occur soon. There needs to be a way for local administrators to remove a bypass/block ahead of its normal expiry time, to force a retry after a problem at the other end is known to have been fixed. 2.6. Subnet Opportunism In principle, when the Source or Destination host belongs to a subnet and the corresponding SG is willing to provide tun- nels to the whole subnet, this should be done. There is no extra overhead, and considerable potential for avoiding later overhead if similar communication occurs with other members of the subnet. Unfortunately, at the moment, oppor- tunistic tunnels can only have degenerate subnets (single hosts) at their ends. (This does, at least, set up the key- ing channel, so that negotiations for tunnels to other hosts in the same subnets will be considerably faster.) The crucial problem is step 11 of section 2.2: the Responder must verify that the Initiator is authorized to represent the Source, and this is impossible for a subnet because there is no way to do a reverse lookup on it. Information in DNS records for a name or a single address cannot be trusted, because they may be controlled by people who do not control the whole subnet. Draft 4 3 May 2001 13 Opportunistic Encryption Ahem: Except in the special case of a subnet masked on a byte boundary (in which case RFC 1035's convention of an incomplete in-addr.arpa name could be used), subnet lookup would need extensions to the reverse-map name space, perhaps along the lines of that commonly done for RFC 2317 delega- tion. IPv6 already has suitable name syntax, as in RFC 2874, but has no specific provisions for subnet entries in its reverse maps. Fixing all this is is not conceptually difficult, but is logically independent of opportunistic encryption, and will be proposed separately. A less-troublesome problem is that the Initiator, in step 10 of 2.2, must know exactly what subnet is present on the Responder's end so he can propose a tunnel to it. This information could be included in the TXT record of the Des- tination (it would have to be verified with a subnet lookup, but that could be done in parallel with other operations). The Initiator presumably can be configured to know what sub- net(s) are present on its end. 2.7. Option Settings IPsec and IKE have far too many useless options, and a few useful ones. IKE negotiation is quite simplistic, and can- not handle even simple discrepancies between the two SGs. So it is necessary to be quite specific about what should be done and what should be proposed, to guarantee interoper- ability without prearrangement or other negotiation proto- cols. Rationale: The prohibition of other negotiations is simply because there is no time. The setup algorithm (section 2.2) is lengthy already. [Open question: should opportunistic IKE use a different port than normal IKE?] Somewhat arbitrarily and tentatively, opportunistic SGs must support Main Mode, Oakley group 5 for D-H, 3DES encryption and MD5 authentication for both ISAKMP and IPsec SAs, RSA/MD5 digital-signature authentication with keys between 2048 and 8192 bits, and ESP doing both encryption and authentication. They must do key PFS in Quick Mode, but not identity PFS. They may support IPComp, preferably using Deflate, but must not insist on it. They may support AES as an alternative to 3DES, but must not insist on it. Rationale: Identity PFS essentially requires establishing a complete new keying channel for each new tunnel, but key PFS just does a new Diffie-Hellman exchange for each rekeying, which is relatively cheap. Keying channels must remain in existence at least as long as any tunnel created with them remains (they are not costly, Draft 4 3 May 2001 14 Opportunistic Encryption and keeping the management path up and available simplifies various issues). See section 3.1 for related issues. Given the use of key PFS, frequent rekeying does not seem critical here. In the absence of strong reason to do otherwise, the Initiator should propose rekeying at 8hr-or-1MB. The Responder must accept any proposal which specifies a rekey- ing time between 1hr and 24hr inclusive and a rekeying vol- ume between 100KB and 10MB inclusive. Given the short expected useful life of most tunnels (see section 3.1), very few of them will survive long enough to be rekeyed. In the absence of strong reason to do other- wise, the Initiator should propose rekeying at 1hr-or-100MB. The Responder must accept any proposal which specifies a rekeying time between 10min and 8hr inclusive and a rekeying volume between 1MB and 1000MB inclusive. It is highly desirable to add some random jitter to the times of actual rekeying attempts, to break up ``convoys'' of rekeying events; this and certain other aspects of robust rekeying practice will be the subject of a separate design proposal. Rationale: The numbers used here for rekeying intervals are chosen quite arbitrarily and should be re-assessed after some implementation experience is gathered. 3. Renewal and Teardown 3.1. Aging When to tear tunnels down is a bit problematic, but if we're setting up a potentially unbounded number of them, we have to tear them down somehow sometime. Set a short initial tentative lifespan, say 1min, since most net flows in fact last only a few seconds. When that expires, look to see if the tunnel is still in use (defini- tion: has had traffic, in either direction, in the last half of the tentative lifespan). If so, assign it a somewhat longer tentative lifespan, say 20min, after which, look again. If not, close it down. (This tentative lifespan is independent of rekeying; it is just the time when the tun- nel's future is next considered. This should happen reason- ably frequently, unlike rekeying, which is costly and shouldn't be too frequent.) Multi-step backoff algorithms are not worth the trouble; looking every 20min doesn't seem onerous. 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 coming, while the demise of the only Draft 4 3 May 2001 15 Opportunistic Encryption TCP connection through a tunnel is a strong hint that none is. If the SG and the client host are separate machines, though, tracking TCP connection status requires packet snooping, which is complicated and probably not worthwhile. IKE keying channels likewise are torn down when it appears the need has passed. They always linger longer than the last tunnel they administer, in case they are needed again; the cost of retaining them is low. Other than that, unless the number of keying channels on the SG gets large, the SG should simply retain all of them until rekeying time, since rekeying is the only costly event. When about to rekey a keying channel which has no current tunnels, note when the last actual keying-channel traffic occurred, and close the keying channel down if it wasn't in the last, say, 30min. When rekeying a keying channel (or perhaps shortly before rekeying is expected), Initiator and Responder should re- fetch the public keys used for SG authentication, against the possibility that they have changed or disappeared. See section 2.7 for discussion of rekeying intervals. Given the low user impact of tearing down and rebuilding a connection (a tunnel or a keying channel), rekeying attempts should not be too persistent: one can always just rebuild when needed, so heroic efforts to preserve an existing con- nection are unnecessary. Say, try every 10s for a minute and every minute for 5min, and then give up and declare the connection (and all other connections to that IKE peer) dead. Rationale: In future, more sophisticated, versions of this protocol, examining the initial packet might permit a more intelligent guess at the tunnel's useful life. HTTP connec- tions in particular are notoriously bursty and repetitive. Rationale: Note that rekeying a keying connection basically consists of building a new keying connection from scratch, using IKE Phase 1, and abandoning the old one. 3.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. Tunnels need to be con- sidered 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 Draft 4 3 May 2001 16 Opportunistic Encryption received for the outbound SAs, try re-sending the original Delete. Three tries spaced 10s apart seems a reasonable level of effort. (Indefinite persistence is not necessary; whether the other end isn't cooperating because it doesn't feel like it, or because it is down/disconnected/etc., the problem will eventually be cleared up by other means.) 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'' keying channel does not arise. Rationale: The pairing of Delete notifications effectively constitutes an acknowledged Delete, which is highly desir- able. 3.3. Outages and 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. Heartbeat mechanisms are somewhat unsatisfactory for this. Unless they are very frequent, which causes other problems, they do not detect the problem promptly. Ahem: What is really wanted is authenticated ICMP. This might be a case where public-key encryption/authentication of network packets is the right thing to do, despite the expense. In the absence of that, a two-part approach seems warranted. First, when an SG receives an IPsec packet that is addressed to it, and otherwise appears healthy, but specifies an unknown SA and is from a host that the receiver currently has no keying channel to, the receiver must attempt to inform the sender via an IKE Initial-Contact notification (necessarily sent in plaintext, since there is no suitable Draft 4 3 May 2001 17 Opportunistic Encryption keying channel). This must be severely rate-limited on both ends; one notification per SG pair per minute seems ample. Second, there is an obvious difficulty with this: the Ini- tial-Contact notification is unauthenticated and cannot be trusted. So it must be taken as a hint only: there must be a way to confirm it. What is needed here is something that's desirable for debug- ging and testing anyway: an IKE-level ping mechanism. Ping- ing direct at the IP level instead will not tell us about a crash/reboot event. Sending pings through tunnels has vari- ous complications (they should stop at the far mouth of the tunnel instead of going on to a subnet; they should not count against idle timers; etc.). What is needed is a con- tinuity check on a keying channel. (This could also be used as a heartbeat, should that seem useful.) IKE Ping delivery need not be reliable, since the whole point of a ping is simply to provoke an acknowledgement. They should preferably be authenticated, but it is not clear that this is absolutely necessary, although if they are not they need encryption plus a timestamp or a nonce, to foil replay mischief. How they are implemented is a secondary issue, and a separate design proposal will be prepared. Ahem: Some existing implementations are already using (pri- vate) notify value 30000 (``LIKE_HELLO'') as ping and (pri- vate) notify value 30002 (``SHUT_UP'') as ping reply. If an IKE Ping gets no response, try some (say 8) IP pings, spaced a few seconds apart, to check IP connectivity; if one comes back, try another IKE Ping; if that gets no response, the other end probably has rebooted, or otherwise been re- initialized, and its tunnels and keying channel(s) should be torn down. In a similar vein, giving limited rekeying persistence, a short network outage could take some tunnels down without disrupting others. On receiving a packet for an unknown SA from a host that a keying channel is currently open to, send that host a Invalid-SPI notification for that SA. The other host can then tear down the half-torn-down tunnel, and nego- tiate a new tunnel for the traffic it presumably still wants to send. Finally, it would be helpful if SGs made some attempt to deal intelligently with crashes and reboots. A deliberate shutdown should include an attempt to notify all other SGs currently connected by keying channels, 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 Draft 4 3 May 2001 18 Opportunistic Encryption 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. 4. Conclusions This design appears to achieve the objective of setting up encryption with strangers. The authentication aspects also seem adequately addressed if the destination controls its reverse-map DNS entries and the DNS data itself can be reli- ably authenticated as having originated from the legitimate administrators of that subnet/FQDN. The authentication sit- uation is less satisfactory when DNS is less helpful, but it is difficult to see what else could be done about it. 5. References [TBW] 6. Appendix: Separate Design Proposals TBW o How can we build a web of trust with DNSSEC? (See sec- tion 2.3.4.) o How can we extend DNS reverse lookups to permit reverse lookup on a subnet? (Both address and mask must appear in the name to be looked up.) (See section 2.6.) o How can rekeying be done as robustly as possible? (At least partly, this is just documenting current FreeS/WAN practice.) (See section 2.7.) o How should IKE Pings be implemented? (See section 3.3.) Draft 4 3 May 2001 19