path: root/doc/draft-spencer-ipsec-ike-implementation.nr

.\" 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.