- New upstream release, now _with_ XAUTH support.

1 files changed, 1203 insertions, 0 deletions

diff --git a/doc/draft-spencer-ipsec-ike-implementation.nr b/doc/draft-spencer-ipsec-ike-implementation.nr
new file mode 100644
index 000000000..5b5776e22
--- /dev/null
+++ b/doc/draft-spencer-ipsec-ike-implementation.nr
@@ -0,0 +1,1203 @@
+.\" date, expiry date, copyright year, and revision
+.DA "26 Feb 2002"
+.ds e "26 Aug 2002
+.ds c 2002
+.ds r 02
+.\" boilerplate
+.pl 10i
+.nr PL 10i
+.po 0
+.nr PO 0
+.ll 7.2i
+.nr LL 7.2i
+.lt 7.2i
+.nr LT 7.2i
+.hy 0
+.nr HY 0
+.ad l
+.nr PD 1v
+.\" macros for paragraph, section header, reference, TOC
+.de P
+.br
+.LP
+.in 3
+..
+.de H
+.br
+.ne 5
+.LP
+.in 0
+..
+.de R
+.IP "   [\\$1]" 14
+..
+.de T
+.ie \\$1=1 \{\
+.nf
+.ta \n(LLu-3nR
+.\}
+.el \{\
+.fi
+.\}
+..
+.de S
+.ie '\\$1'' \\$2 \a \\$3
+.el \\$1. \\$2 \a \\$3
+..
+.\" headers/footers
+.ds LH "Internet Draft
+.ds CH "IKE Implementation Issues
+.ds RH "\*(DY
+.ds LF "Spencer & Redelmeier
+.ds CF "
+.ds RF "[Page %]
+.\" and let's get started
+.RT
+.nf
+.tl 'Network Working Group''Henry Spencer'
+.tl 'Internet Draft''SP Systems'
+.tl 'Expires: \*e''D. Hugh Redelmeier'
+.tl '''Mimosa Systems'
+.tl '''\*(DY'
+.sp
+.ce 99
+IKE Implementation Issues
+<draft-spencer-ipsec-ike-implementation-\*r.txt>
+.ce 0
+.H
+Status of this Memo
+.P
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC2026.
+.P
+(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.
+.P
+Distribution of this memo is unlimited.
+.P
+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.
+.P
+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."
+.P
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt.
+.P
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+.P
+This Internet-Draft will expire on \*e.
+.H
+Copyright Notice
+.P
+Copyright (C) The Internet Society \*c.  All Rights Reserved.
+.bp
+.H
+Table of Contents
+.P
+.T 1
+.S "1" "Introduction" "3"
+.S "2" "Lower-level Background and Notes" "4"
+.S "2.1" "Packet Handling" "4"
+.S "2.2" "Ciphers" "5"
+.S "2.3" "Interfaces" "5"
+.S "3" "IKE Infrastructural Issues" "5"
+.S "3.1" "Continuous Channel" "5"
+.S "3.2" "Retransmission" "5"
+.S "3.3" "Replay Prevention" "6"
+.S "4" "Basic Keying and Rekeying" "7"
+.S "4.1" "When to Create SAs" "7"
+.S "4.2" "When to Rekey" "8"
+.S "4.3" "Choosing an SA" "9"
+.S "4.4" "Why to Rekey" "9"
+.S "4.5" "Rekeying ISAKMP SAs" "10"
+.S "4.6" "Bulk Negotiation" "10"
+.S "5" "Deletions, Teardowns, Crashes" "11"
+.S "5.1" "Deletions" "11"
+.S "5.2" "Teardowns and Shutdowns" "12"
+.S "5.3" "Crashes" "13"
+.S "5.4" "Network Partitions" "13"
+.S "5.5" "Unknown SAs" "14"
+.S "6" "Misc. IKE Issues" "16"
+.S "6.1" "Groups 1 and 5" "16"
+.S "6.2" "To PFS Or Not To PFS" "16"
+.S "6.3" "Debugging Tools, Lack Thereof" "16"
+.S "6.4" "Terminology, Vagueness Thereof" "17"
+.S "6.5" "A Question of Identity" "17"
+.S "6.6" "Opportunistic Encryption" "17"
+.S "6.7" "Authentication and RSA Keys" "17"
+.S "6.8" "Misc. Snags" "18"
+.S "7" "Security Considerations" "19"
+.S "8" "References" "19"
+.S "" "Authors' Addresses" "20"
+.S "" "Full Copyright Statement" "21"
+.T 0
+.bp
+.H
+Abstract
+.P
+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.
+.P
+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.
+.P
+This is offered as an Informational RFC.
+.P
+This -\*r 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).
+.H
+1. Introduction
+.P
+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.
+.P
+The Linux FreeS/WAN implementation of IPsec interoperates
+with almost every other IPsec implementation,
+and because of its free nature,
+it also sees some use as a reference implementation by other implementors.
+The high degree of interoperability is noteworthy
+given its organizers' strong minimalist bias,
+which has caused them to implement only
+a small subset of the full glory of IPsec.
+This document describes how the FreeS/WAN project has resolved
+some of the gaps in the IPsec specifications
+(and plans to resolve some others),
+and what difficulties have been encountered,
+in hopes that this generally-successful experience
+might be informative to new implementors.
+.P
+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.
+.H
+2. Lower-level Background and Notes
+.H
+2.1. Packet Handling
+.P
+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.
+.P
+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.
+.P
+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.
+.H
+2.2. Ciphers
+.P
+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!
+.P
+See also section 6.1 for a consequence of our insistence on 3DES.
+.H
+2.3. Interfaces
+.P
+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.
+.H
+3. IKE Infrastructural Issues
+.P
+A number of problems in IPsec connection management become easier if
+some attention is first paid to providing an infrastructure
+to support solving them.
+.H
+3.1. Continuous Channel
+.P
+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.
+.P
+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).
+.H
+3.2. Retransmission
+.P
+The unreliable nature of UDP transmission is a nuisance.
+IKE implementations should always be prepared to retransmit the most recent
+message they sent on an ISAKMP SA,
+since there is some possibility that the other end did not get it.
+This means, in particular,
+that the system sending the supposedly-last message of an exchange
+cannot relax and assume that the exchange is complete,
+at least not until a significant timeout has elapsed.
+.P
+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).
+.P
+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.
+.P
+(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.)
+.P
+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.
+.H
+3.3. Replay Prevention
+.P
+The unsequenced nature of UDP transmission is also troublesome,
+because it means that higher levels must consider the possibility
+of replay attacks.
+FreeS/WAN takes the position that systematically eliminating this
+possibility at a low level is strongly preferable to forcing careful
+consideration of possible impacts at every step of an exchange.
+RFC 2408 [ISAKMP] section 3.1 states that the Message ID of an
+ISAKMP message must be "unique".
+FreeS/WAN interprets this literally,
+as forbidding duplication of Message IDs
+within the set of all messages sent via a single ISAKMP SA.
+.P
+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\(emin our experience
+it has not\(emthe ISAKMP SA can be rekeyed early to collect the garbage.
+.P
+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.
+.P
+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.
+.H
+4. Basic Keying and Rekeying
+.H
+4.1. When to Create SAs
+.P
+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.
+.P
+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).
+.P
+With this approach, the Commit Bit is useless,
+and we ignore it.
+In fact, until quite recently we discarded any IKE message containing it,
+and this caused surprisingly few interoperability problems;
+apparently it is not widely used.
+We have recently been persuaded that simply ignoring it is preferable;
+preliminary experience with this indicates that the result is successful
+interoperation with implementations which set it.
+.H
+4.2. When to Rekey
+.P
+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.)
+.P
+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.)
+.P
+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.
+.P
+Having the Initiator lead the way is an obvious way of deciding
+who should speak first,
+since there is already an Initiator/Responder asymmetry in the connection.
+Moreover, our experience has been that Initiator lead gives a significantly
+higher probability of successful negotiation!
+The negotiation process itself is asymmetric,
+because the Initiator must make a few specific proposals which the Responder
+can only accept or reject,
+so the Initiator must try to guess where its "acceptable" region
+(in parameter space)
+might overlap with the Responder's.
+We have seen situations where negotiations would succeed or fail
+depending on which end initiated them,
+because one 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.
+.P
+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.
+.H
+4.3. Choosing an SA
+.P
+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.
+.P
+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.)
+.H
+4.4. Why to Rekey
+.P
+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.
+.P
+Volume-based expiry does add some minor complications.
+In particular, it makes explicit Delete of now-disused SAs more 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.
+.P
+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".
+.H
+4.5. Rekeying ISAKMP SAs
+.P
+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.
+.P
+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.
+.P
+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.
+.P
+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.
+.H
+4.6. Bulk Negotiation
+.P
+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.
+.H
+5. Deletions, Teardowns, Crashes
+.P
+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.
+.H
+5.1. Deletions
+.P
+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.
+.P
+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.
+.P
+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.
+.P
+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.
+.P
+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.
+.P
+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.
+.P
+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).
+.H
+5.2. Teardowns and Shutdowns
+.P
+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.
+.P
+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.
+.P
+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.
+.P
+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.
+.P
+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 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.
+.H
+5.3. Crashes
+.P
+Systems sometimes crash.
+Coping with the resulting loss of information is easily the most
+difficult problem we have found in implementing robust IPsec systems.
+.P
+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.)
+.P
+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.
+.P
+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.
+.H
+5.4. Network Partitions
+.P
+A network partition, making the two ends unable to reach each other,
+has many of the same characteristics as having the other end crash... until
+the network reconnects.
+It is desirable that recovery from this be automatic.
+.P
+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.
+.P
+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.)
+.P
+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.
+.H
+5.5. Unknown SAs
+.P
+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\(emif
+the non-rebooted host has no traffic to send,
+it does not care whether the connection is intact\(embut
+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.
+.P
+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 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.
+.P
+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\(emwhich still thinks it has a connection\(emchecks
+whether the connection still works,
+and renegotiates if not.
+.P
+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.
+.P
+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.
+.P
+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 probably worth determining by experiment whether the other end
+supports IKE ping, and remembering that.)
+.P
+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.
+.H
+6. Misc. IKE Issues
+.H
+6.1. Groups 1 and 5
+.P
+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.
+.P
+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.
+.H
+6.2. To PFS Or Not To PFS
+.P
+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.
+.P
+We do not explicitly support the other flavor of PFS,
+for identities [IKE, section 8],
+and this has caused no interoperability problems.
+.H
+6.3. Debugging Tools, Lack Thereof
+.P
+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.
+.P
+It's also quite common to have IKE negotiate a connection successfully,
+but to have some firewall along the way blocking ESP.
+Users find this mysterious and difficult to diagnose.
+We have no immediate suggestions on what could be done about it.
+.H
+6.4. Terminology, Vagueness Thereof
+.P
+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.
+.P
+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.
+.P
+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.
+.H
+6.5. A Question of Identity
+.P
+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"?
+.P
+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?
+.P
+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.
+.H
+6.6. Opportunistic Encryption
+.P
+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.
+.H
+6.7. Authentication and RSA Keys
+.P
+We provide two IKE authentication methods:
+shared secrets ("pre-shared keys")
+and RSA digital signatures.
+(A user-provided add-on package generalizes the latter to limited
+support for certificates;
+we have not worked extensively with it ourselves yet and cannot comment
+on it yet.)
+.P
+Shared secrets, despite their administrative difficulties,
+see considerable use,
+and are also the method of last resort for interoperability problems.
+.P
+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.
+.P
+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.
+.P
+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.
+.H
+6.8. Misc. Snags
+.P
+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 interoperability failures here.
+.P
+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.
+.P
+Similarly, there is nothing in the specs which says that ISAKMP cookies
+must be non-zero, but zero cookies will in fact cause trouble.
+.H
+7. Security Considerations
+.P
+Since this document discusses aspects of building robust and
+interoperable IPsec implementations,
+security considerations permeate it.
+.H
+8. References
+.R AH
+Kent, S., and Atkinson, R.,
+"IP Authentication Header",
+RFC 2402,
+Nov 1998.
+.R CIPHERS
+Pereira, R., and Adams, R.,
+"The ESP CBC-Mode Cipher Algorithms",
+RFC 2451,
+Nov 1998.
+.R CRACK
+Electronic Frontier Foundation,
+"Cracking DES:
+Secrets of Encryption Research, Wiretap Politics and Chip Design",
+O'Reilly 1998,
+ISBN 1-56592-520-3.
+.R DES
+Madson, C., and Doraswamy, N.,
+"The ESP DES-CBC Cipher Algorithm",
+RFC 2405,
+Nov 1998.
+.R DNSRSA
+D. Eastlake 3rd,
+"RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)",
+RFC 3110,
+May 2001.
+.R ESP
+Kent, S., and Atkinson, R.,
+"IP Encapsulating Security Payload (ESP)",
+RFC 2406,
+Nov 1998.
+.R 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).
+.R IKE
+Harkins, D., and Carrel, D.,
+"The Internet Key Exchange (IKE)",
+RFC 2409, Nov 1998.
+.R IPSEC
+Kent, S., and Atkinson, R.,
+"Security Architecture for the Internet Protocol",
+RFC 2401, Nov 1998.
+.R ISAKMP
+Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
+"Internet Security Association and Key Management Protocol (ISAKMP)",
+RFC 2408, Nov 1998.
+.R 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).
+.R PKCS1v1
+Kaliski, B.,
+"PKCS #1: RSA Encryption, Version 1.5",
+RFC 2313, March 1998.
+.R PKCS1v2
+Kaliski, B., and Staddon, J.,
+"PKCS #1: RSA Cryptography Specifications, Version 2.0",
+RFC 2437, Oct 1998.
+.R PFKEY
+McDonald, D., Metz, C., and Phan, B.,
+"PF_KEY Key Management API, Version 2",
+RFC 2367, July 1998.
+.R REKEY
+Tim Jenkins, "IPsec Re-keying Issues",
+<draft-jenkins-ipsec-rekeying-06.txt>,
+2 May 2000 (draft expired, work no longer in progress).
+.R REPLAY
+Krywaniuk, A.,
+"Using Isakmp Message Ids for Replay Protection",
+<draft-krywaniuk-ipsec-antireplay-00.txt>,
+9 July 2001
+(work in progress).
+.R 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.
+.R SCHNEIER
+Bruce Schneier, "Applied Cryptography", 2nd ed.,
+Wiley 1996, ISBN 0-471-11709-9.
+.R SECFAIL
+Karn, P., and Simpson, W.,
+"ICMP Security Failures Messages",
+RFC 2521,
+March 1999.
+.H
+Authors' Addresses
+.P
+.nf
+.ne 8
+Henry Spencer
+SP Systems
+Box 280 Stn. A
+Toronto, Ont. M5W1B2
+Canada
+
+henry@spsystems.net
+416-690-6561
+.ne 8
+.sp 2
+D. Hugh Redelmeier
+Mimosa Systems Inc.
+29 Donino Ave.
+Toronto, Ont. M4N2W6
+Canada
+
+hugh@mimosa.com
+416-482-8253
+.bp
+.H
+Full Copyright Statement
+.P
+Copyright (C) The Internet Society \*c. 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.