2013.10.24

[uclinux-h8/uClinux-dist.git] / freeswan / doc / draft-spencer-ipsec-ike-implementation.txt

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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f