Network Working Group Henry Spencer Internet Draft SP Systems Expires: 14 May 2002 D. Hugh Redelmeier Mimosa Systems 14 Nov 2001 IKE Implementation Issues Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. If approved as an Informational RFC... This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 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 14 May 2002. Copyright Notice Copyright (C) The Internet Society 2001. All Rights Reserved. Spencer & Redelmeier [Page 1] Internet Draft IKE Implementation Issues 14 Nov 2001 Table of Contents [xxx to be provided] Spencer & Redelmeier [Page 2] Internet Draft IKE Implementation Issues 14 Nov 2001 Abstract The current IPsec specifications for key exchange and connection management, RFCs 2408 [ISAKMP] and 2409 [IKE], leave many aspects of connection management unspecified, most prominently rekeying practices. We can hope that future revisions of the specifications will clear this up. Meanwhile, it seems useful to set down some successful experiences, to minimize the extent to which new implementors have to rely on unwritten folklore. The Linux FreeS/WAN implementation of IPsec interoperates with almost every other IPsec implementation. This document describes how the FreeS/WAN project has resolved some of the gaps in the IPsec specifications (and plans to resolve some others), and what difficulties have been encountered, in hopes that this generally- successful experience might be informative to new implementors. This is offered as an Informational RFC. 1. Introduction The current IPsec specifications for key exchange and connection management, RFCs 2408 [ISAKMP] and 2409 [IKE], leave many aspects of connection management unspecified, most prominently rekeying practices. This is a cryptic puzzle which each group of implementors has to struggle with, and differences in how the ambiguities and gaps are resolved are potentially a fruitful source of interoperability problems. We can hope that future revisions of the specifications will clear this up. Meanwhile, it seems useful to set down some successful experiences, to minimize the extent to which new implementors have to rely on unwritten folklore. The Linux FreeS/WAN implementation of IPsec interoperates with almost every other IPsec implementation, and because of its free nature, it also sees some use as a reference implementation by other implementors. The high degree of interoperability is noteworthy given its organizers' strong minimalist bias, which has caused them to implement only a small subset of the full glory of IPsec. This document describes how the FreeS/WAN project has resolved some of the gaps in the IPsec specifications (and plans to resolve some others), and what difficulties have been encountered, in hopes that this generally-successful experience might be informative to new implementors. One small caution about applicability: this experience may not be relevant to severely resource-constrained implementations. FreeS/WAN's target environment is previous-generation PCs, now available at trivial cost (often, within an organization, at no Spencer & Redelmeier [Page 3] Internet Draft IKE Implementation Issues 14 Nov 2001 cost), which have quite impressive CPU power and memory by the standards of only a few years ago. Some of the approaches discussed here may be inapplicable to implementations with severe external constraints which prevent them from taking advantage of modern hardware technology. 2. Lower-level Background and Notes FreeS/WAN implements ESP [ESP] and AH [AH] straightforwardly, although AH sees little use among our users. Our ESP/AH implementation cannot currently handle packets with IP options; somewhat surprisingly, this has caused little difficulty. We insist on encryption and do not support authentication-only connections, and this has not caused significant difficulty either. MTU and fragmentation issues, by contrast, have been a constant headache. We will not describe the details of our current approach to them, because it still needs work. One difficulty we have encountered is that many combinations of packet source and packet destination apparently cannot cope with an "interior minimum" in the path MTU, e.g. where an IPsec tunnel intervenes and its headers reduce the MTU for an intermediate link. This is particularly prevalent when using common PC software to connect to large well- known web sites; we think it is largely due to misconfigured firewalls which do not pass ICMP Fragmentation Required messages. The only solution we have yet found is to lie about the MTU of the tunnel, accepting the (undesirable) fragmentation of the ESP packets for the sake of preserving connectivity. We currently zero out the TOS field of ESP packets, rather than copying it from the inner header, on the grounds that it lends itself too well to traffic analysis and covert channels. We provide an option to restore RFC 2401 [IPSEC] copying behavior, but this appears to see little use. We initially implemented both DES [DES] and 3DES [CIPHERS] for both IKE and ESP, but after the Deep Crack effort [CRACK] demonstrated its inherent insecurity, we dropped support for DES. Somewhat surprisingly, our insistence on 3DES has caused almost no interoperability problems, despite DES being officially mandatory. A very few other systems either do not support 3DES or support it only as an optional upgrade, which inconveniences a few would-be users. There have also been one or two cases of systems which don't quite seem to know the difference! See also section 6.xxx for a consequence of our insistence on 3DES. Spencer & Redelmeier [Page 4] Internet Draft IKE Implementation Issues 14 Nov 2001 We currently employ PF_KEY version 2 [PFKEY], plus various non- standard extensions, as our interface between keying and ESP/AH. This has not proven entirely satisfactory. Our feeling now is that keying issues and policy issues do not really lend themselves to the clean separation that PF_KEY envisions. 3. IKE Infrastructural Issues A number of problems in IPsec connection management become easier if some attention is first paid to providing an infrastructure to support solving them. 3.1. Continuous Channel FreeS/WAN uses an approximation to the "continuous channel" model, in which ISAKMP SAs are maintained between IKEs so long as any IPsec SAs are open between the two systems. The resource consumption of this is minor: the only substantial overhead is occasional rekeying. IPsec SA management becomes significantly simpler if there is always a channel for transmission of control messages. We suggest (although we do not yet fully implement this) that inability to maintain (e.g., to rekey) this control path should be grounds for tearing down the IPsec SAs as well. 3.2. Retransmission The unreliable nature of UDP transmission is a nuisance. IKE implementations should always be prepared to retransmit the most recent message they sent on an ISAKMP SA, since there is some possibility that the other end did not get it. This means, in particular, that the system sending the supposedly-last message of an exchange cannot relax and assume that the exchange is complete, at least not until a significant timeout has elapsed. Systems must also retain information about the message most recently received in an exchange, so that a duplicate of it can be detected (and possibly interpreted as a NACK for the response). The retransmission rules FreeS/WAN follows are: (1) if a reply is expected, retransmit only if it does not appear before a timeout; and (2) if a reply is not expected (last message of the exchange), retransmit only on receiving a retransmission of the previous message. Notably, in case (1) we do NOT retransmit on receiving a retransmission, which avoids possible congestion problems arising from packet duplication, at the price of slowing response to packet loss. These retransmission rules have been entirely successful. Spencer & Redelmeier [Page 5] Internet Draft IKE Implementation Issues 14 Nov 2001 3.3. Replay Prevention The unsequenced nature of UDP transmission is also troublesome, because it means that higher levels must consider the possibility of replay attacks. FreeS/WAN takes the position that systematically eliminating this possibility at a low level is strongly preferable to forcing careful consideration of possible impacts at every step of an exchange. RFC 2408 [ISAKMP] section 3.1 states that the Message ID of an ISAKMP message must be "unique". FreeS/WAN interprets this literally, as forbidding duplication of Message IDs within the set of all messages sent via a single ISAKMP SA. This requires remembering all Message IDs until the ISAKMP SA is superseded by rekeying, but that is not costly (four bytes per sent or received message), and it ELIMINATES replay attacks from consideration; we believe this investment of resources is well worthwhile. If the resource consumption becomes excessive--in our experience it has not--the ISAKMP SA can be rekeyed early to collect the garbage. There is theoretically an interoperability problem when talking to implementations which interpret "unique" more loosely and may re-use Message IDs, but it has not been encountered in practice. This approach appears to be completely interoperable. The proposal by Andrew Krywaniuk [REPLAY], which advocates turning the Message ID into an anti-replay counter, would achieve the same goal without the minor per-message memory overhead. This may be preferable, although it means an actual protocol change and more study is needed. 4. Basic Keying and Rekeying 4.1. When to Create SAs As Tim Jenkins [REKEY] pointed out, there is a potential race condition in Quick Mode: a fast lightly-loaded Initiator might start using IPsec SAs very shortly after sending QM3 (the third and last message of Quick Mode), while a slow heavily-loaded Responder might not be ready to receive them until after spending a significant amount of time creating its inbound SAs. The problem is even worse if QM3 gets lost. FreeS/WAN's approach to this is what Jenkins called "Responder Pre- Setup": the Responder creates its inbound IPsec SAs before it sends QM2, so they are always ready and waiting when the Initiator sends QM3 and begins sending traffic. This approach is simple and reliable, and in our experience it interoperates with everybody. Its Spencer & Redelmeier [Page 6] Internet Draft IKE Implementation Issues 14 Nov 2001 only real weakness is the possibility of replay attacks, but since we have eliminated those by other means (see section 3.3), that's not an issue. With this approach, the Commit Bit is useless, and we ignore it. In fact, until quite recently we discarded any IKE message containing it, and this caused surprisingly few interoperability problems; apparently it is not widely used. We have recently been persuaded that simply ignoring it is preferable; preliminary experience with this indicates that the result is successful interoperation with implementations which set it. 4.2. When to Rekey To preserve connectivity for user traffic, rekeying of a connection (that is, creation of new IPsec SAs to supersede the current ones) must begin before its current IPsec SAs expire. Preferably one end should predictably start rekeying negotiations first, to avoid the extra overhead of two simultaneous negotiations, although either end should be prepared to rekey if the other does not. There is also a problem with "convoys" of keying negotiations: a "hub" gateway with many IPsec connections can be inundated with rekeying negotiations exactly one connection-expiry time after it reboots, and the massive overload this induces tends to make this situation self-perpetuating, so it recurs regularly. FreeS/WAN has the concept of a "rekeying margin". If FreeS/WAN was the Initiator for the previous rekeying (or the startup, if none) of the connection, it nominally starts rekeying negotiations that long before expiry. However, some random jitter is added to break up convoys: rather than starting rekeying at the margin, it will start at a random time between the margin and twice the margin. If FreeS/WAN was the Responder for the previous rekeying/startup, and nothing has been heard from the previous Initiator when only half the margin remains, FreeS/WAN will initiate rekeying negotiations. No jitter is applied (perhaps it should be). Having the Initiator lead the way is an obvious way of deciding who should speak first, since there is already an Initiator/Responder asymmetry in the connection. Moreover, our experience has been that Initiator lead gives a significantly higher probability of successful negotiation! The negotiation process itself is asymmetric, because the Initiator must make a few specific proposals which the Responder can only accept or reject, so the Initiator must try to guess where its "acceptable" region (in parameter space) might overlap with the Responder's. We have seen situations where negotiations would succeed or fail depending on which end initiated them, because one Spencer & Redelmeier [Page 7] Internet Draft IKE Implementation Issues 14 Nov 2001 end was better at guessing. Given an existing connection, we KNOW that the previous Initiator was able to initiate a successful negotiation, so it should (if at all possible) take the lead again. FreeS/WAN defaults the rekeying margin to 9 minutes, although this can be changed by configuration. There is also a configuration option to adjust the permissible range of jitter. The defaults were chosen somewhat arbitrarily, but they work extremely well and the configuration options are rarely used. 4.3. Choosing an SA Once rekeying has occurred, both old and new IPsec SAs for the connection exist, at least momentarily. FreeS/WAN accepts incoming traffic on either old or new inbound SAs, but sends outgoing traffic only on the new outbound ones. This approach appears to be significantly more robust than using the old ones until they expire, notably in cases where renegotiation has occurred because something has gone wrong on the other end. It avoids having to pay meticulous attention to the state of the other end, state which is difficult to learn reliably given the limitations of IKE. This approach has interoperated successfully with ALMOST all other implementations. The only (well-characterized) problem cases have been implementations which rely on receiving a DELETE message for the old SAs to tell them to switch over to the new ones. Since delivery of DELETE is unreliable, this seems like a serious mistake. This is all the more true because DELETE announces that the deletion has already occurred [ISAKMP, section 3.15], not that it is about to occur, so packets already in transit in the other direction could be lost. DELETE should be used for resource cleanup, not for switchover control. (These matters are discussed further in section 5.) 4.4. Why to Rekey xxx traffic-based rekeying vs time-based. xxx margins should not be large enough to require "using it all up". 4.5. Rekeying ISAKMP SAs The above discussion has focused on rekeying for IPsec SAs, but FreeS/WAN applies the same approaches to rekeying for ISAKMP SAs, with similar success. 4.6. Bulk Negotiation Quick Mode nominally provides for negotiating possibly-large numbers of similar but unrelated IPsec SAs simultaneously [IKE, section 9]. Spencer & Redelmeier [Page 8] Internet Draft IKE Implementation Issues 14 Nov 2001 Nobody appears to do this. FreeS/WAN does not support it, and its absence has caused no problems. 5. Deletions, Teardowns, Crashes FreeS/WAN currently ignores all notifications and DELETEs, and never generates them. This has caused little difficulty in interoperability, which shouldn't be surprising (since notification and DELETE support is officially entirely optional) but does seem to surprise some people. Nevertheless, we do plan some changes to this approach based on past experience. 5.1. Deletions xxx shortly after rekeying, Responder DELETEs old, Initiator responds with its own DELETE (connection considered bidirectional), resource cleanup not switchover control, but does help interop with broken implementations. 5.2. Teardowns and Shutdowns xxx teardown by bidirectional deletes. xxx shutdown notification? xxx use initial-contact as final-contact, doing both jobs? 5.3. Crashes xxx address inertia for post-crash notification. xxx initial-contact and IKE ping, vs authentication problems. xxx for initial-contact, what's a "system"? xxx Invalid SPI notification. 6. Misc. IKE Issues xxx support for group 1 dropped, too small, not enough randomness for 3DES, few problems ensued. xxx PFS: two kinds, neither negotiated nor announced, frequent minor stumbling block. xxx IKE ping, IKE finger. xxx terminology needs work: "group" for associated SAs, "keying channel", "connection", two kinds of PFS. Spencer & Redelmeier [Page 9] Internet Draft IKE Implementation Issues 14 Nov 2001 7. Security Considerations Since this document discusses aspects of building robust and interoperable IPsec implementations, security considerations permeate it. References [AH] xxx to be filled in [CIPHERS] xxx to be filled in [CRACK] xxx to be filled in [DES] xxx to be filled in [ESP] xxx to be filled in [IKE] xxx to be filled in [IPSEC] xxx to be filled in [ISAKMP] xxx to be filled in [PFKEY] xxx to be filled in [REKEY] Tim Jenkins, "IPsec Re-keying Issues", , 2 May 2000 (draft expired, work no longer in progress). [REPLAY] Krywaniuk, A., "Using Isakmp Message Ids for Replay Protection", , 12 July 2001 (work in progress). Author's Addresses Henry Spencer SP Systems Box 280 Stn. A Toronto, Ont. M5W1B2 Canada henry@spsystems.net 416-690-6561 Spencer & Redelmeier [Page 10] Internet Draft IKE Implementation Issues 14 Nov 2001 D. Hugh Redelmeier Mimosa Systems Inc. 29 Donino Ave. Toronto, Ont. M4N2W6 Canada hugh@mimosa.com 416-482-8253 Spencer & Redelmeier [Page 11] Internet Draft IKE Implementation Issues 14 Nov 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 implmentation 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. Spencer & Redelmeier [Page 12]