- Updated to new upstream version.

1 files changed, 1232 insertions, 0 deletions

diff --git a/doc/draft-spencer-ipsec-ike-implementation.txt b/doc/draft-spencer-ipsec-ike-implementation.txt
new file mode 100644
index 000000000..145c00ba8
--- /dev/null
+++ b/doc/draft-spencer-ipsec-ike-implementation.txt
@@ -0,0 +1,1232 @@
+
+
+
+Network Working Group                                      Henry Spencer
+Internet Draft                                                SP Systems
+Expires: 26 Aug 2002                                  D. Hugh Redelmeier
+                                                          Mimosa Systems
+                                                             26 Feb 2002
+
+                       IKE Implementation Issues
+            <draft-spencer-ipsec-ike-implementation-02.txt>
+
+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 26 Aug 2002.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2002.  All Rights Reserved.
+
+
+
+
+
+
+
+
+
+
+Spencer & Redelmeier                                            [Page 1]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+Table of Contents
+
+   1. Introduction ................................................... 3
+   2. Lower-level Background and Notes ............................... 4
+   2.1. Packet Handling .............................................. 4
+   2.2. Ciphers ...................................................... 5
+   2.3. Interfaces ................................................... 5
+   3. IKE Infrastructural Issues ..................................... 5
+   3.1. Continuous Channel ........................................... 5
+   3.2. Retransmission ............................................... 5
+   3.3. Replay Prevention ............................................ 6
+   4. Basic Keying and Rekeying ...................................... 7
+   4.1. When to Create SAs ........................................... 7
+   4.2. When to Rekey ................................................ 8
+   4.3. Choosing an SA ............................................... 9
+   4.4. Why to Rekey ................................................. 9
+   4.5. Rekeying ISAKMP SAs ......................................... 10
+   4.6. Bulk Negotiation ............................................ 10
+   5. Deletions, Teardowns, Crashes ................................. 11
+   5.1. Deletions ................................................... 11
+   5.2. Teardowns and Shutdowns ..................................... 12
+   5.3. Crashes ..................................................... 13
+   5.4. Network Partitions .......................................... 13
+   5.5. Unknown SAs ................................................. 14
+   6. Misc. IKE Issues .............................................. 16
+   6.1. Groups 1 and 5 .............................................. 16
+   6.2. To PFS Or Not To PFS ........................................ 16
+   6.3. Debugging Tools, Lack Thereof ............................... 16
+   6.4. Terminology, Vagueness Thereof .............................. 17
+   6.5. A Question of Identity ...................................... 17
+   6.6. Opportunistic Encryption .................................... 17
+   6.7. Authentication and RSA Keys ................................. 17
+   6.8. Misc. Snags ................................................. 18
+   7. Security Considerations ....................................... 19
+   8. References .................................................... 19
+   Authors' Addresses ............................................... 20
+   Full Copyright Statement ......................................... 21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Spencer & Redelmeier                                            [Page 2]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+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.  Pending clarifications in future revisions of the
+   specifications, this document sets 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.
+
+   This -02 revision mainly: discusses ISAKMP SA expiry during IPsec-SA
+   rekeying (4.5), revises the discussion of bidirectional Deletes
+   (5.1), suggests remembering the parameters of successful negotiations
+   for later use (4.2, 5.3), notes an unsuccessful negotiation from the
+   other end as a hint of a possibly broken connection (5.5), and adds
+   sections on network partitions (5.4), authentication methods and the
+   subtleties of RSA public keys (6.7), and miscellaneous
+   interoperability concerns (6.8).
+
+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
+
+
+
+Spencer & Redelmeier                                            [Page 3]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   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
+   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
+
+2.1. Packet Handling
+
+   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.
+
+
+
+
+
+
+Spencer & Redelmeier                                            [Page 4]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+2.2. Ciphers
+
+   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.1 for a consequence of our insistence on 3DES.
+
+2.3. Interfaces
+
+   We currently employ PF_KEY version 2 [PFKEY], plus various non-
+   standard extensions, as our interface between keying and ESP.  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.
+
+   As a corollary of this, there is one and only one ISAKMP SA
+   maintained between a pair of IKEs (although see sections 5.3 and 6.5
+   for minor complications).
+
+3.2. Retransmission
+
+   The unreliable nature of UDP transmission is a nuisance.  IKE
+   implementations should always be prepared to retransmit the most
+
+
+
+Spencer & Redelmeier                                            [Page 5]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   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.  The timeout for case (1) is 10 seconds for the first retry, 20
+   seconds for the second, and 40 seconds for all subsequent retries
+   (normally only one, except when configuration settings call for
+   persistence and the message is the first message of Main Mode with a
+   new peer).  These retransmission rules have been entirely successful.
+
+   (Michael Thomas of Cisco has pointed out that the retry timeouts
+   should include some random jitter, to de-synchronize hosts which are
+   initially synchronized by, e.g., a power outage.  We already jitter
+   our rekeying times, as noted in section 4.2, but that does not help
+   with initial startup.  We're implementing jittered retries, but
+   cannot yet report on experience with this.)
+
+   There is a deeper problem, of course, when an entire "exchange"
+   consists of a single message, e.g. the ISAKMP Informational Exchange.
+   Then there is no way to decide whether or when a retransmission is
+   warranted at all.  This seems like poor design, to put it mildly (and
+   there is now talk of fixing it).  We have no experience in dealing
+   with this problem at this time, although it is part of the reason why
+   we have delayed implementing Notification messages.
+
+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
+
+
+
+Spencer & Redelmeier                                            [Page 6]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   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 delayed or 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.
+   (There is potentially still a problem if FreeS/WAN is the Initiator
+   and the Responder does not use Responder Pre-Setup, but no such
+   problems have been seen.)  The only real weakness of Responder Pre-
+   Setup is the possibility of replay attacks, which we have eliminated
+   by other means (see section 3.3).
+
+   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
+
+
+
+Spencer & Redelmeier                                            [Page 7]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   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: for example, 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.  (Convoys can also evolve
+   gradually from initially-unsynchronized negotiations.)
+
+   FreeS/WAN has the concept of a "rekeying margin", measured in
+   seconds.  If FreeS/WAN was the Initiator for the previous rekeying
+   (or the startup, if none) of the connection, it nominally starts
+   rekeying negotiations at expiry time minus one rekeying margin.  Some
+   random jitter is added to break up convoys: rather than starting
+   rekeying exactly at minus one margin, it starts at a random time
+   between minus one margin and minus two margins.  (The randomness here
+   need not be cryptographic in quality, so long as it varies over time
+   and between hosts.  We use an ordinary PRNG seeded with a few bytes
+   from a cryptographic randomness source.  The seeding mostly just
+   ensures that the PRNG sequence is different for different hosts, even
+   if they start up simultaneously.)
+
+   If FreeS/WAN was the Responder for the previous rekeying/startup, and
+   nothing has been heard from the previous Initiator at expiry time
+   minus one-half the rekeying margin, FreeS/WAN will initiate rekeying
+   negotiations.  No jitter is applied; we now believe that it should be
+   jittered, say between minus one-half margin and minus one-quarter
+   margin.
+
+   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
+
+
+
+Spencer & Redelmeier                                            [Page 8]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   succeed or fail depending on which end initiated them, because one
+   end was making better guesses.  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.
+   Also, the Responder should remember the Initiator's successful
+   proposal, and start from that rather than from his own default
+   proposals if he must take the lead; we don't currently implement this
+   completely but plan to.
+
+   FreeS/WAN defaults the rekeying margin to 9 minutes, although this
+   can be changed by configuration.  There is also a configuration
+   option to alter 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, and support for Delete is optional, this
+   reliance 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
+
+   FreeS/WAN currently implements only time-based expiry (life in
+   seconds), although we are working toward supporting volume-based
+   expiry (life in kilobytes) as well.  The lack of volume-based expiry
+   has not been an interoperability problem so far.
+
+   Volume-based expiry does add some minor complications.  In
+   particular, it makes explicit Delete of now-disused SAs more
+
+
+
+Spencer & Redelmeier                                            [Page 9]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   important, because once an SA stops being used, it might not expire
+   on its own.  We believe this lacks robustness and is generally
+   unwise, especially given the lack of a reliable Delete, and expect to
+   use volume-based expiry only as a supplement to time-based expiry.
+   However, Delete support (see section 5) does seem advisable for use
+   with volume-based expiry.
+
+   We do not believe that volume-based expiry alters the desirability of
+   switching immediately to the new SAs after rekeying.  Rekeying
+   margins are normally a small fraction of the total life of an SA, so
+   we feel there is no great need to "use 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.
+
+   One issue which we have noticed, but not explicitly dealt with, is
+   that difficulties may ensue if an IPsec-SA rekeying negotiation is in
+   progress at the time when the relevant ISAKMP SA gets rekeyed.  The
+   IKE specification [IKE] hints, but does not actually say, that a
+   Quick Mode negotiation should remain on a single ISAKMP SA
+   throughout.
+
+   A reasonable rekeying margin will generally prevent the old ISAKMP SA
+   from actually expiring during a negotiation.  Some attention may be
+   needed to prevent in-progress negotiations from being switched to the
+   new ISAKMP SA.  Any attempt at pre-expiry deletion of the ISAKMP SA
+   must be postponed until after such dangling negotiations are
+   completed, and there should be enough delay between ISAKMP-SA
+   rekeying and a deletion attempt to (more or less) ensure that there
+   are no negotiation-starting packets still in transit from before the
+   rekeying.
+
+   At present, FreeS/WAN does none of this, and we don't KNOW of any
+   resulting trouble.  With normal lifetimes, the problem should be
+   uncommon, and we speculate that an occasional disrupted negotiation
+   simply gets retried.
+
+4.6. Bulk Negotiation
+
+   Quick Mode nominally provides for negotiating possibly-large numbers
+   of similar but unrelated IPsec SAs simultaneously [IKE, section 9].
+   Nobody appears to do this.  FreeS/WAN does not support it, and its
+   absence has caused no problems.
+
+
+
+
+
+Spencer & Redelmeier                                           [Page 10]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+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
+
+   As hinted at above, we plan to implement Delete support, done as
+   follows.  Shortly after rekeying of IPsec SAs, the Responder issues a
+   Delete for its old inbound SAs (but does not actually delete them
+   yet).  The Responder initiates this because the Initiator started
+   using the new SAs on sending QM3, while the Responder started using
+   them only on (or somewhat after) receiving QM3, so there is less
+   chance of old-SA packets still being in transit from the Initiator.
+   The Initiator issues an unsolicited Delete only if it does not hear
+   one from the Responder after a longer delay.
+
+   Either party, on receiving a Delete for one or more of the old
+   outbound SAs of a connection, deletes ALL the connection's SAs, and
+   acknowledges with a Delete for the old inbound SAs.  A Delete for
+   nonexistent SAs (e.g., SAs which have already been expired or
+   deleted) is ignored.  There is no retransmission of unacknowledged
+   Deletes.
+
+   In the normal case, with prompt reliable transmission (except
+   possibly for loss of the Responder's initial Delete) and conforming
+   implementations on both ends, this results in three Deletes being
+   transmitted, resembling the classic three-way handshake.  Loss of a
+   Delete after the first, or multiple losses, will cause the SAs not to
+   be deleted on at least one end.  It appears difficult to do much
+   better without at least a distinction between request and
+   acknowledgement.
+
+   RFC 2409 section 9 "strongly suggests" that there be no response to
+   informational messages such as Deletes, but the only rationale
+   offered is prevention of infinite loops endlessly exchanging "I don't
+   understand you" informationals.  Since Deletes cannot lead to such a
+   loop (and in any case, the nonexistent-SA rule prevents more than one
+   acknowledgement for the same connection), we believe this
+   recommendation is inapplicable here.
+
+   As noted in section 4.3, these Deletes are intended for resource
+   cleanup, not to control switching between SAs.  But we expect that
+   they will improve interoperability with some broken implementations.
+
+
+
+Spencer & Redelmeier                                           [Page 11]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   We believe strongly that connections need to be considered as a
+   whole, rather than treating each SA as an independent entity.  We
+   will issue Deletes only for the full set of inbound SAs of a
+   connection, and will treat a Delete for any outbound SA as equivalent
+   to deletion of all the outbound SAs for the associated connection.
+
+   The above is phrased in terms of IPsec SAs, but essentially the same
+   approach can be applied to ISAKMP SAs (the Deletes for the old ISAKMP
+   SA should be sent via the new one).
+
+5.2. Teardowns and Shutdowns
+
+   When a connection is not intended to be up permanently, there is a
+   need to coordinate teardown, so that both ends are aware that the
+   connection is down.  This is both for recovery of resources, and to
+   avoid routing packets through dangling SAs which can no longer
+   deliver them.
+
+   Connection teardown will use the same bidirectional exchange of
+   Deletes as discussed in section 5.1: a Delete received for current
+   IPsec SAs (not yet obsoleted by rekeying) indicates that the other
+   host wishes to tear down the associated connection.
+
+   A Delete received for a current ISAKMP SA indicates that the other
+   host wishes to tear down not only the ISAKMP SA but also all IPsec
+   SAs currently under the supervision of that ISAKMP SA.  The 5.1
+   bidirectional exchange might seem impossible in this case, since
+   reception of an ISAKMP-SA Delete indicates that the other end will
+   ignore further traffic on that ISAKMP SA.  We suggest using the same
+   tactic discussed in 5.1 for IPsec SAs: the first Delete is sent
+   without actually doing the deletion, and the response to receiving a
+   Delete is to do the deletion and reply with another Delete.  If there
+   is no response to the first Delete, retry a small number of times and
+   then give up and do the deletion; apart from being robust against
+   packet loss, this also maximizes the probability that an
+   implementation which does not do the bidirectional Delete will
+   receive at least one of the Deletes.
+
+   When a host with current connections knows that it is about to shut
+   down, it will issue Deletes for all SAs involved (both IPsec and
+   ISAKMP), advising its peers (as per the meaning of Delete [ISAKMP,
+   section 3.15]) that the SAs have become useless.  It will ignore
+   attempts at rekeying or connection startup thereafter, until it shuts
+   down.
+
+   It would be better to have a Final-Contact notification, analogous to
+   Initial-Contact but indicating that no new negotiations should be
+   attempted until further notice.  Initial-Contact actually could be
+
+
+
+Spencer & Redelmeier                                           [Page 12]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   used for shutdown notification (!), but in networks where connections
+   are intended to exist permanently, it seems likely to provoke
+   unwanted attempts to renegotiate the lost connections.
+
+5.3. Crashes
+
+   Systems sometimes crash.  Coping with the resulting loss of
+   information is easily the most difficult problem we have found in
+   implementing robust IPsec systems.
+
+   When connections are intended to be permanent, it is simple to
+   specify renegotiation on reboot.  With our approach to SA selection
+   (see section 4.3), this handles such cases robustly and well.  We do
+   have to tell users that BOTH hosts should be set this way.  In cases
+   where crashes are synchronized (e.g. by power interruptions), this
+   may result in simultaneous negotiations at reboot.  We currently
+   allow both negotiations to proceed to completion, but our use-newest
+   selection method effectively ignores one connection or the other, and
+   when one of them rekeys, we notice that the new SAs replace those of
+   both old connections, and we then refrain from rekeying the other.
+   (This duplicate detection is desirable in any event, for robustness,
+   to ensure that the system converges on a reasonable state eventually
+   after it is perturbed by difficulties or bugs.)
+
+   When connections are not permanent, the situation is less happy.  One
+   particular situation in which we see problems is when a number of
+   "Road Warrior" hosts occasionally call in to a central server.  The
+   server is normally configured not to initiate such connections, since
+   it does not know when the Road Warrior is available (or what IP
+   address it is using).  Unfortunately, if the server crashes and
+   reboots, any Road Warriors then connected have a problem: they don't
+   know that the server has crashed, so they can't renegotiate, and the
+   server has forgotten both the connections and their (transient) IP
+   addresses, so it cannot renegotiate.
+
+   We believe that the simplest answer to this problem is what John
+   Denker has dubbed "address inertia": the server makes a best-effort
+   attempt to remember (in nonvolatile storage) which connections were
+   active and what the far-end addresses were (and what the successful
+   proposal's parameters were), so that it can attempt renegotiation on
+   reboot.  We have not implemented this yet, but intend to; Denker has
+   implemented it himself, although in a somewhat messy way, and reports
+   excellent results.
+
+5.4. Network Partitions
+
+   A network partition, making the two ends unable to reach each other,
+   has many of the same characteristics as having the other end crash...
+
+
+
+Spencer & Redelmeier                                           [Page 13]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   until the network reconnects.  It is desirable that recovery from
+   this be automatic.
+
+   If the network reconnects before any rekeying attempts or other IKE
+   activities occurred, recovery is fully transparent, because the IKEs
+   have no idea that there was any problem.  (Complaints such as ICMP
+   Host Unreachable messages are unauthenticated and hence cannot be
+   given much weight.)  This fits the general mold of TCP/IP: if nobody
+   wanted to send any traffic, a network outage doesn't matter.
+
+   If IKE activity did occur, the IKE implementation will discover that
+   the other end doesn't seem to be responding.  The preferred response
+   to this depends on the nature of the connection.  If it was intended
+   to be ephemeral (e.g. opportunistic encryption [OE]), closing it down
+   after a few retries is reasonable.  If the other end is expected to
+   sometimes drop the connection without warning, it may not be
+   desirable to retry at all.  (We support both these forms of
+   configurability, and indeed we also have a configuration option to
+   suppress rekeying entirely on one end.)
+
+   If the connection was intended to be permanent, however, then
+   persistent attempts to re-establish it are appropriate.  Some degree
+   of backoff is appropriate here, so that retries get less frequent as
+   the outage gets prolonged.  Backoff should be limited, so that re-
+   established connectivity is not followed by a long delay before a
+   retry.  Finally, after many retries (say 24 hours' worth), it may be
+   preferable to just declare the connection down and rely on manual
+   intervention to re-establish it, should this be desirable.  We do not
+   yet fully support all this.
+
+5.5. Unknown SAs
+
+   A more complete solution to crashes would be for an IPsec host to
+   note the arrival of ESP packets on an unknown IPsec SA, and report it
+   somehow to the other host, which can then decide to renegotiate.
+   This arguably might be preferable in any case--if the non-rebooted
+   host has no traffic to send, it does not care whether the connection
+   is intact--but delays and packet loss will be reduced if the
+   connection is renegotiated BEFORE there is traffic for it.  So
+   unknown-SA detection is best reserved as a fallback method, with
+   address inertia used to deal with most such cases.
+
+   A difficulty with unknown-SA detection is, just HOW should the other
+   host be notified?  IKE provides no good way to do the notification:
+   Notification payloads (e.g., Initial-Contact) are unauthenticated
+   unless they are sent under protection of an ISAKMP SA.  A "Security
+   Failures - Bad SPI" ICMP message [SECFAIL] is an interesting
+   alternative, but has the disadvantage of likewise being
+
+
+
+Spencer & Redelmeier                                           [Page 14]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   unauthenticated.  It's fundamentally unlikely that there is a simple
+   solution to this, given that almost any way of arranging or checking
+   authentication for such a notification is costly.
+
+   We think the best answer to this is a two-step approach.  An
+   unauthenticated Initial-Contact or Security Failures - Bad SPI cannot
+   be taken as a reliable report of a problem, but can be taken as a
+   hint that a problem MIGHT exist.  Then there needs to be some
+   reliable way of checking such hints, subject to rate limiting since
+   the checks are likely to be costly (and checking the same connection
+   repeatedly at short intervals is unlikely to be worthwhile anyway).
+   So the rebooted host sends the notification, and the non-rebooted
+   host--which still thinks it has a connection--checks whether the
+   connection still works, and renegotiates if not.
+
+   Also, if an IPsec host which believes it has a connection to another
+   host sees an unsuccessful attempt by that host to negotiate a new
+   one, that is also a hint of possible problems, justifying a check and
+   possible renegotiation.  ("Unsuccessful" here means a negotiation
+   failure due to lack of a satisfactory proposal.  A failure due to
+   authentication failure suggests a denial-of-service attack by a third
+   party, rather than a genuine problem on the legitimate other end.)
+   As noted in section 4.2, it is possible for negotiations to succeed
+   or fail based on which end initiates them, and some robustness
+   against that is desirable.
+
+   We have not yet decided what form the notification should take.  IKE
+   Initial-Contact is an obvious possibility, but has some
+   disadvantages.  It does not specify which connection has had
+   difficulties.  Also, the specification [IKE section 4.6.3.3] refers
+   to "remote system" and "sending system" without clearly specifying
+   just what "system" means; in the case of a multi-homed host using
+   multiple forms of identification, the question is not trivial.
+   Initial-Contact does have the fairly-decisive advantage that it is
+   likely to convey the right general meaning even to an implementation
+   which does not do things exactly the way ours does.
+
+   A more fundamental difficulty is what form the reliable check takes.
+   What is wanted is an "IKE ping", verifying that the ISAKMP SA is
+   still intact (it being unlikely that IPsec SAs have been lost while
+   the ISAKMP SA has not).  The lack of such a facility is a serious
+   failing of IKE.  An acknowledged Notification of some sort would be
+   ideal, but there is none at present.  Some existing implementations
+   are known to use the private Notification values 30000 as ping and
+   30002 as ping reply, and that seems the most attractive choice at
+   present.  If it is not recognized, there will probably be no reply,
+   and the result will be an unnecessary renegotiation, so this needs
+   strict rate limiting.  (Also, when a new connection is set up, it's
+
+
+
+Spencer & Redelmeier                                           [Page 15]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   probably worth determining by experiment whether the other end
+   supports IKE ping, and remembering that.)
+
+   While we think this facility is desirable, and is about the best that
+   can be done with the poor tools available, we have not gotten very
+   far in implementation and cannot comment intelligently about how well
+   it works or interoperates.
+
+6. Misc. IKE Issues
+
+6.1. Groups 1 and 5
+
+   We have dropped support for the first Oakley Group (group 1), despite
+   it being officially mandatory, on the grounds that it is grossly too
+   weak to provide enough randomness for 3DES.  There have been some
+   interoperability problems, mostly quite minor: ALMOST everyone
+   supports group 2 as well, although sometimes it has to be explicitly
+   configured.
+
+   We also support the quasi-standard group 5 [GROUPS].  This has not
+   been seriously exercised yet, because historically we offered group 2
+   first and almost everyone accepted it.  We have recently changed to
+   offering group 5 first, and no difficulties have been reported.
+
+6.2. To PFS Or Not To PFS
+
+   A persistent small interoperability problem is that the presence or
+   absence of PFS (for keys [IKE, section 5.5]) is neither negotiated
+   nor announced.  We have it enabled by default, and successful
+   interoperation often requires having the other end turn it on in
+   their implementation, or having the FreeS/WAN end disable it.  Almost
+   everyone supports it, but it's usually not the default, and
+   interoperability is often impossible unless the two ends somehow
+   reach prior agreement on it.
+
+   We do not explicitly support the other flavor of PFS, for identities
+   [IKE, section 8], and this has caused no interoperability problems.
+
+6.3. Debugging Tools, Lack Thereof
+
+   We find IKE lacking in basic debugging tools.  Section 5.4, above,
+   notes that an IKE ping would be useful for connectivity verification.
+   It would also be extremely helpful for determining that UDP/500
+   packets get back and forth successfully between the two ends, which
+   is often an important first step in debugging.
+
+   It's also quite common to have IKE negotiate a connection
+   successfully, but to have some firewall along the way blocking ESP.
+
+
+
+Spencer & Redelmeier                                           [Page 16]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   Users find this mysterious and difficult to diagnose.  We have no
+   immediate suggestions on what could be done about it.
+
+6.4. Terminology, Vagueness Thereof
+
+   The terminology of IPsec needs work.  We feel that both the
+   specifications and user-oriented documentation would be greatly
+   clarified by concise, intelligible names for certain concepts.
+
+   We semi-consistently use "group" for the set of IPsec SAs which are
+   established in one direction by a single Quick Mode negotiation and
+   are used together to process a packet (e.g., an ESP SA plus an AH
+   SA), "connection" for the logical packet path provided by a
+   succession of pairs of groups (each rekeying providing a new pair,
+   one group in each direction), and "keying channel" for the
+   corresponding supervisory path provided by a sequence of ISAKMP SAs.
+
+   We think it's a botch that "PFS" is used to refer to two very
+   different things, but we have no specific new terms to suggest, since
+   we only implement one kind of PFS and thus can just ignore the other.
+
+6.5. A Question of Identity
+
+   One specification problem deserves note: exactly when can an existing
+   phase 1 negotiation be re-used for a new phase 2 negotiation, as IKE
+   [IKE, section 4] specifies?  Presumably, when it connects the same
+   two "parties"... but exactly what is a "party"?
+
+   As noted in section 5.4, in cases involving multi-homing and multiple
+   identities, it's not clear exactly what criteria are used for
+   deciding whether the intended far end for a new negotiation is the
+   same one as for a previous negotiation.  Is it by Identification
+   Payload?  By IP address?  Or what?
+
+   We currently use a somewhat-vague notion of "identity", basically
+   what gets sent in Identification Payloads, for this, and this seems
+   to be successful, but we think this needs better specification.
+
+6.6. Opportunistic Encryption
+
+   Further IKE challenges appear in the context of Opportunistic
+   Encryption [OE], but operational experience with it is too limited as
+   yet for us to comment usefully right now.
+
+6.7. Authentication and RSA Keys
+
+   We provide two IKE authentication methods: shared secrets ("pre-
+   shared keys") and RSA digital signatures.  (A user-provided add-on
+
+
+
+Spencer & Redelmeier                                           [Page 17]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   package generalizes the latter to limited support for certificates;
+   we have not worked extensively with it ourselves yet and cannot
+   comment on it yet.)
+
+   Shared secrets, despite their administrative difficulties, see
+   considerable use, and are also the method of last resort for
+   interoperability problems.
+
+   For digital signatures, we have taken the somewhat unorthodox
+   approach of using "bare" RSA public keys, either supplied in
+   configuration files or fetched from DNS, rather than getting involved
+   in the complexity of certificates.  We encode our RSA public keys
+   using the DNS KEY encoding [DNSRSA] (aka "RFC 2537", although that
+   RFC is now outdated), which has given us no difficulties and which we
+   highly recommend.  We have seen two difficulties in connection with
+   RSA keys, however.
+
+   First, while a number of IPsec implementations are able to take
+   "bare" RSA public keys, each one seems to have its own idea of what
+   format should be used for transporting them.  We've had little
+   success with interoperability here, mostly because of key-format
+   issues; the implementations generally WILL interoperate successfully
+   if you can somehow get an RSA key into them at all, but that's hard.
+   X.509 certificates seem to be the lowest (!)  common denominator for
+   key transfer.
+
+   Second, although the content of RSA public keys has been stable,
+   there has been a small but subtle change over time in the content of
+   RSA private keys.  The "internal modulus", used to compute the
+   private exponent "d" from the public exponent "e" (or vice-versa) was
+   originally [RSA] [PKCS1v1] [SCHNEIER] specified to be (p-1)*(q-1),
+   where p and q are the two primes.  However, more recent definitions
+   [PKCS1v2] call it "lambda(n)" and define it to be lcm(p-1, q-1); this
+   appears to be a minor optimization.  The result is that private keys
+   generated with the new definition often fail consistency checks in
+   implementations using the old definition.  Fortunately, it is seldom
+   necessary to move private keys around.  Our software now consistently
+   uses the new definition (and thus will accept keys generated with
+   either definition), but our key generator also has an option to
+   generate old-definition keys, for the benefit of users who upgrade
+   their networks incrementally.
+
+6.8. Misc. Snags
+
+   Nonce size is another characteristic that is neither negotiated nor
+   announced but that the two ends must somehow be able to agree on.
+   Our software accepts anything between 8 and 256, and defaults to 16.
+   These numbers were chosen rather arbitrarily, but we have seen no
+
+
+
+Spencer & Redelmeier                                           [Page 18]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   interoperability failures here.
+
+   Nothing in the ISAKMP [ISAKMP] or IKE [IKE] specifications says
+   explicitly that a normal Message ID must be non-zero, but a zero
+   Message ID in fact causes failures.
+
+   Similarly, there is nothing in the specs which says that ISAKMP
+   cookies must be non-zero, but zero cookies will in fact cause
+   trouble.
+
+7. Security Considerations
+
+   Since this document discusses aspects of building robust and
+   interoperable IPsec implementations, security considerations permeate
+   it.
+
+8. References
+
+   [AH]       Kent, S., and Atkinson, R., "IP Authentication Header",
+              RFC 2402, Nov 1998.
+
+   [CIPHERS]  Pereira, R., and Adams, R., "The ESP CBC-Mode Cipher
+              Algorithms", RFC 2451, Nov 1998.
+
+   [CRACK]    Electronic Frontier Foundation, "Cracking DES: Secrets of
+              Encryption Research, Wiretap Politics and Chip Design",
+              O'Reilly 1998, ISBN 1-56592-520-3.
+
+   [DES]      Madson, C., and Doraswamy, N., "The ESP DES-CBC Cipher
+              Algorithm", RFC 2405, Nov 1998.
+
+   [DNSRSA]   D. Eastlake 3rd, "RSA/SHA-1 SIGs and RSA KEYs in the
+              Domain Name System (DNS)", RFC 3110, May 2001.
+
+   [ESP]      Kent, S., and Atkinson, R., "IP Encapsulating Security
+              Payload (ESP)", RFC 2406, Nov 1998.
+
+   [GROUPS]   Kivinen, T., and Kojo, M., "More MODP Diffie-Hellman
+              groups for IKE", <draft-ietf-ipsec-ike-modp-
+              groups-04.txt>, 13 Dec 2001 (work in progress).
+
+   [IKE]      Harkins, D., and Carrel, D., "The Internet Key Exchange
+              (IKE)", RFC 2409, Nov 1998.
+
+   [IPSEC]    Kent, S., and Atkinson, R., "Security Architecture for the
+              Internet Protocol", RFC 2401, Nov 1998.
+
+
+
+
+
+Spencer & Redelmeier                                           [Page 19]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   [ISAKMP]   Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
+              "Internet Security Association and Key Management Protocol
+              (ISAKMP)", RFC 2408, Nov 1998.
+
+   [OE]       Richardson, M., Redelmeier, D. H., and Spencer, H., "A
+              method for doing opportunistic encryption with IKE",
+              <draft-richardson-ipsec-opportunistic-06.txt>, 21 Feb 2002
+              (work in progress).
+
+   [PKCS1v1]  Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC
+              2313, March 1998.
+
+   [PKCS1v2]  Kaliski, B., and Staddon, J., "PKCS #1: RSA Cryptography
+              Specifications, Version 2.0", RFC 2437, Oct 1998.
+
+   [PFKEY]    McDonald, D., Metz, C., and Phan, B., "PF_KEY Key
+              Management API, Version 2", RFC 2367, July 1998.
+
+   [REKEY]    Tim Jenkins, "IPsec Re-keying Issues", <draft-jenkins-
+              ipsec-rekeying-06.txt>, 2 May 2000 (draft expired, work no
+              longer in progress).
+
+   [REPLAY]   Krywaniuk, A., "Using Isakmp Message Ids for Replay
+              Protection", <draft-krywaniuk-ipsec-antireplay-00.txt>, 9
+              July 2001 (work in progress).
+
+   [RSA]      Rivest, R.L., Shamir, A., and Adleman, L., "A Method for
+              Obtaining Digital Signatures and Public-Key
+              Cryptosystems", Communications of the ACM v21n2, Feb 1978,
+              p. 120.
+
+   [SCHNEIER] Bruce Schneier, "Applied Cryptography", 2nd ed., Wiley
+              1996, ISBN 0-471-11709-9.
+
+   [SECFAIL]  Karn, P., and Simpson, W., "ICMP Security Failures
+              Messages", RFC 2521, March 1999.
+
+Authors' Addresses
+
+   Henry Spencer
+   SP Systems
+   Box 280 Stn. A
+   Toronto, Ont. M5W1B2
+   Canada
+
+   henry@spsystems.net
+   416-690-6561
+
+
+
+
+Spencer & Redelmeier                                           [Page 20]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+   D. Hugh Redelmeier
+   Mimosa Systems Inc.
+   29 Donino Ave.
+   Toronto, Ont. M4N2W6
+   Canada
+
+   hugh@mimosa.com
+   416-482-8253
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Spencer & Redelmeier                                           [Page 21]
+
+Internet Draft          IKE Implementation Issues            26 Feb 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society 2002. 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 22]
+