Internet Engineering Task Force Tim Jenkins
IP Security Working Group TimeStep Corporation
Internet Draft April 14, 1999
IPSec Re-keying Issues
<draft-jenkins-ipsec-rekeying-01.txt>
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Status of this Memo
Informational
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) Tim Jenkins (1999). All Rights Reserved.
IPSec Working Group Expires October 14, 1999 [Page 1]
Internet Draft IPSec Re-keying Issues April 1999
Table of Contents
1. Introduction...................................................3
2. Phase 2 SA Re-keying...........................................3
2.1 Phase 2 Re-keying Issues......................................3
2.1.1 Inconsistent SA Use Recommendation..........................4
2.1.2 Observed Behaviours.........................................4
2.1.3 SA Set-up Race Condition....................................5
2.1.4 Commit Bit Interaction......................................7
2.2 Solution Examination..........................................8
2.2.1 Responder Pre-Set Up........................................8
2.2.1.1 Normal Conditions.........................................8
2.2.1.2 Dropped Packet Conditions................................10
2.2.1.3 Failed Negotiation.......................................11
2.2.1.4 Responder Pre-Set Up Security Hole.......................11
2.2.2 Recommended Re-keying Method...............................12
2.2.2.1 Dropped Quick Mode 3 Message.............................13
2.2.2.2 Absence of Traffic.......................................13
2.2.2.3 Compatibility With Observed Behaviours...................14
2.2.2.4 Compatibility with Commit Bit............................14
2.2.2.5 Implementation Notes.....................................15
2.3 Conclusions..................................................15
3. Phase 1 Re-keying.............................................15
3.1 Phase 1 Re-keying Requirements...............................15
3.1.1 Multiple SA Usage..........................................16
3.1.2 INITIAL-CONTACT Notification...............................17
3.1.3 DELETE Notification........................................17
3.1.4 Re-keying Timing...........................................17
4. Next IPSec Version Recommendations............................17
4.1 Re-transmission Rules........................................18
4.1.1 Main Mode Re-Transmission Rules............................18
4.1.2 Aggressive Mode Re-Transmission Rules......................19
4.1.3 Quick Mode Re-Transmission Rules...........................19
4.2 SA Delete Mode...............................................19
4.3 Phase 1 Re-keying for IPSecond...............................20
4.4 Phase 2 Re-keying for IPSecond...............................20
4.4.1 Oldest Phase 2 SA First....................................21
4.4.2 Phase 2 Re-keying Illustration.............................21
4.5 Commit Bit Replacement.......................................24
4.5.1 DEFER_USAGE Notification...................................24
4.5.2 Allow Usage Mode...........................................25
4.5.3 CONNECTED Notification.....................................25
5. Acknowledgements..............................................26
6. References....................................................26
IPSec Working Group [Page 2]
Internet Draft IPSec Re-keying Issues April 1999
1. Introduction
This document has three primary objectives.
The first objective is to illustrate problems and issues associated
with re-keying within the confines of the current set of IPSec
documents. For a number of reasons, re-keying in IPSec has become
problematic, such that packets can get dropped by IPSec
implementations during re-keying. Worse, there exists the
possibility that IPSec implementations from different vendors may
not be interoperable because of the way they re-key.
The second objective of this paper is to propose methods of
performing both phase 1 and phase 2 re-keying for IPSec
implementations in such a way as to minimise packet loss and to
maximize compatibility.
The initial focus of the first two objectives is on phase 2 re-
keying; it is then extended to phase 1 re-keying. The need for this
document in each case is initially discussed, followed by a
recommendation for re-keying within the protocol framework
established by the initial version of the IPSec documents.
Finally, the third objective of the document is to provide
recommendations for the next version of the IPSec protocols. These
recommendations are made to best solve the re-keying problems in a
manner that is not possible within the constraints of the existing
IPSec documents.
2. Phase 2 SA Re-keying
This section discusses phase 2 re-keying issues and makes
recommendations to minimize the impact of these issues within the
current IPSec document set.
2.1 Phase 2 Re-keying Issues
The issues associated with phase 2 re-keying are listed below. Some
of the points are expanded upon later.
1) There is no specification defining how re-keying is to be done.
2) The existing drafts appear contradictory in their
recommendations on the usage of multiple phase 2 SAs.
IPSec Working Group [Page 3]
Internet Draft IPSec Re-keying Issues April 1999
3) Some recent implementations have shipped with a method of re-
keying that will not perform reliably under real world network
conditions.
4) The use of the DELETE notification is not required.
5) A variety of re-keying behaviours have been observed, some of
which are incompatible.
6) The commit bit is not yet widely implemented, and its use as
described is confusing. Further, while the documentation
requires its support, its use is not required.
7) A race condition exists at SA set up, exacerbating re-keying
issues.
2.1.1 Inconsistent SA Use Recommendation
The issue of inconsistent SA usage recommendations is examined
further here.
From paragraph 2 of Section 9 of [IKE]:
An implementation may wish to negotiate a range of SAs when
performing Quick Mode. By doing this they can speed up the "re-
keying". Quick Mode defines how KEYMAT is defined for a range of
SAs. When one peer feels it is time to change SAs they simply use
the next one within the stated range. A range of SAs can be
established by negotiating multiple SAs (identical attributes,
different SPIs) with one Quick Mode.
While the document does not define what "... the next one ..."
means, this paragraph strongly implies that there is no required
order for the use of phase 2 SAs that have been negotiated within a
phase 1 SA, and that multiple SAs may be pre-negotiated and used at
will.
However, this appears to be contradicted by paragraph 3 of section
4.3 of [ISAKMP]:
Modification of a Protocol SA (phase 2 negotiation) follows the
same procedure as creation of a Protocol SA. The creation of a new
SA is protected by the existing ISAKMP SA. There is no
relationship between the two Protocol SAs. A protocol
implementation SHOULD begin using the newly created SA for
outbound traffic and SHOULD continue to support incoming traffic
on the old SA until it is deleted or until traffic is received
IPSec Working Group [Page 4]
Internet Draft IPSec Re-keying Issues April 1999
under the protection of the newly created SA. As stated previously
in this section, deletion of an old SA is then dependent on local
security policy.
Many implementations have interpreted this to mean that the new SA
should be used for outbound in preference to the old SA. In other
words, the old SA should be abandoned as soon as possible.
This interpretation of [ISAKMP] is in direct conflict with the usage
implied by [IKE], resulting in potential problems.
2.1.2 Observed Behaviours
The following behaviours have been observed by various vendors'
implementations when devices have set up a second phase 2 SA. The
behaviours listed below are not mutually exclusive.
1) The device continues to use the old SA until it naturally
expires, then switches to the new SA.
2) The device immediately begins using the new SA.
3) The device immediately drops the old SA.
4) The device never sends a DELETE notification.
5) The device always sends a DELETE notification.
6) The device deletes the old SA some time after re-keying, but
before the end of its natural lifetime.
7) A device wants to keep more than one SA up all the time.
All of these behaviours are permitted under the current documents.
However, even when quick mode packets are not lost, it can be seen
that interoperability is not always possible with some combinations
of behaviours listed above.
2.1.3 SA Set-up Race Condition
Further, behaviour 2 above is not a good behaviour, as illustrated
below. In this example, the initiator is a gateway capable of
handling full T3 bandwidth rates, while the responder is a PC
running a software IPSec implementation, and it is overloaded.
IPSec Working Group [Page 5]
Internet Draft IPSec Re-keying Issues April 1999
In the illustration, QM1 refers to the first quick mode message, QM2
to the second quick mode message and QM3 to the third quick mode
message.
Initiator Responder
QM1 sent ----
-------
-------------
---------------> QM1 received
|
|
| QM1 processed
|
|
---------------- QM2 sent
-------------
-------
QM2 rec. <----
process |
QM3 sent -----
* -------
packet on new SA -------------
_____ ---------------> QM3 received
_______ |
_____________ | QM3 processing
_______________|
| packet dropped
|
* new SA set up
Figure 2-1 Race Condition Sequence Chart
By the time the responder has set up the new SA, packets protected
by that SA have already started arriving from the initiator. This
causes them to be dropped by the responder. This case is further
complicated by the possibility of packets taking different paths
through the network, so theoretically, the third quick mode message
could arrive after packets protected by the new SA.
Additionally, since all IKE packets are based on UDP, there is no
guarantee that QM3 even arrives at the peer, so making assumptions
about new SA use based on the transmission time of a packet will
still lead to failures in the field.
To reduce the effects of packet loss, some implementations were
observed to blindly transmit QM3 multiple times, back to back.
IPSec Working Group [Page 6]
Internet Draft IPSec Re-keying Issues April 1999
This can reduce the probability that the peer does not get QM3, but
cannot eliminate it. Nor can it eliminate race conditions due to
path differences or processing times.
If the behaviour of the initiator was to delay usage of the new SA
for outbound traffic, this would cause failures for those
implementations that immediately delete the old SA. Therefore, the
behaviour of delaying use of the new SA and immediately deleting the
old SA are incompatible.
2.1.4 Commit Bit Interaction
The use of the commit bit can solve the race condition illustrated
in the previous section when asserted by the responder during quick
mode. However, it suffers from the following problems:
1) Use of the commit bit is not well defined. The present
documentation specifies its use for phase 1 and phase 2, but
mentions phase 2 specific details. There are also issues
related to how the subsequent CONNECTED notification fits in
with the quick mode exchange.
2) While its support is required, its use is not.
3) Its use may make implementations susceptible to a denial of
service attack by forcing initiators to wait for a CONNECTED
notification that may never come. While this is only one of
many very basic possible denial of service attacks on IKE, this
is not an excuse to leave the existing implementation as it is.
4) There is no defined way to recover from the loss of the
CONNECTED notification.
5) Some implementations are using the commit bit for the wrong
reasons.
Point 1 is being addressed by the working group; future versions of
the IPSec documents should clarify these issues.
Point 3 happens because the commit bit is in the ISAKMP header, and
the ISAKMP header is not authenticated, so is susceptible to
modification.
Point 5 above needs some elaboration. In a previous section, it was
mentioned that the loss of the third quick mode message can cause
problems, since the responder will not set up the SA at all. Because
of this, some implementations have chosen to set the commit bit as a
IPSec Working Group [Page 7]
Internet Draft IPSec Re-keying Issues April 1999
mechanism to force the re-transmission of the third quick mode
message.
This is wrong for two reasons. First, it is not the stated purpose
of the commit bit. The purpose of the commit bit is to delay the
usage of an SA, for whatever reason. This implies that it is not a
good mechanism to cause re-transmission of the third quick mode
message.
Secondly, it does not solve the packet loss problem; it only defers
it. The logic of the improper usage is that the initiator will
resend the third quick mode message until it receives the CONNECTED
notification (which is now effectively the fourth quick mode
message).
The problem with this is that it leaves no mechanism for demanding
the re-transmission of the CONNECTED notification itself. It can be
dropped just as the third quick mode message can. This means that
the problem that was intended to be solved by the use of the commit
bit is simply pushed out to being the problem of solving the dropped
CONNECTED notification.
Sections 2.2.2.1 and 4.1 describe a mechanism for solving the
dropped third quick mode message problem.
2.2 Solution Examination
This section details the operation of some possible behaviours, with
the intent of arriving at a best possible phase 2 re-keying
mechanism under the constraints of the existing documents.
In all the examples, the term "sets up a new outbound SA" means that
the new outbound SA will be chosen in favour of the old one. Whether
the SA is actually created before that time or not is implementation
dependent.
2.2.1 Responder Pre-Set Up
As a starting point, the responder pre-set up method of re-keying is
examined. Note that it will work with most of the behaviours
observed in the field.
In this method, SAs are treated separately as inbound and outbound,
as well as old and new. Further, it takes advantage of the fact that
the responder knows what the SA is going to be after the second
quick mode message is sent. By using this information, it allows the
IPSec Working Group [Page 8]
Internet Draft IPSec Re-keying Issues April 1999
responder to set up the new inbound SA before having received the
third quick mode message.
Implicit acknowledgement of the reception of the third quick mode
message by the responder is provided by use of the new SA in the
initiator's inbound direction. The initiator should not use its new
outbound SA before that time.
Additionally, it does not require use of the CONNECTED notification
for prevention of the race condition, or the use of the DELETE
notification for removal of the old SA. This is important since,
even if they are always sent, they are unacknowledged UDP packets
and may be lost.
2.2.1.1 Normal Conditions
Figure 2-2 shows the operation under normal (successful) conditions.
Initiator Responder
Inbound Outbound Inbound Outbound
| | | |
1 ----------------- | |
| | ------------ | |
| | -------------------> 2
| | | | |
| | -------------------- 3
| | ------------ | *4 |
5 <--------------- | | |
| | | | | |
6 ---------------- | | |
| *7 | ------------ | | |
| | | -------------------> 8
| | | | | | |
| | | | | | *
| | | | | | *9
| | | | | *10 |
| | | | | |
| *11 | | | |
| | | *12 | | |
| | *13 | | | |
*14| | | | |
| | | *15 |
| | *16| |
| | | |
Figure 2-2 SA Pre-Set Up Sequence Chart
IPSec Working Group [Page 9]
Internet Draft IPSec Re-keying Issues April 1999
Events
1) Initiator sends first quick mode message.
2) Responder receives first quick mode message.
3) Responder sends second quick mode message.
4) Responder sets up new inbound SA. This is to handle the case
where the initiator starts transmitting on the new SA
immediately after sending the third quick mode message.
5) Initiator receives second quick mode message.
6) Initiator sends third quick mode message.
7) Initiator sets up new inbound SA.
8) Responder receives third quick mode message.
9) Responder sets up new outbound SA.
10) Responder deletes old outbound SA.
11) Traffic from responder to initiator arrives at initiator on new
SA.
12) Initiator sets up new outbound SA.
13) Initiator deletes old outbound SA.
14) Initiator deletes old inbound SA.
15) Traffic from initiator to responder arrives at responder on new
SA.
16) Responder deletes old inbound SA.
While appearing complicated, it enables the lossless transfer from
one SA to another while supporting almost all other behaviours.
Support for and use of the DELETE notification is unchanged.
IPSec Working Group [Page 10]
Internet Draft IPSec Re-keying Issues April 1999
2.2.1.2 Dropped Packet Conditions
In this case, the event list is modified to show what happens when
each packet is dropped once. The event numbers refer to those
illustrated in Figure 2-2.
1) Initiator sends first quick mode message.
e) Packet is dropped during transmission.
1b) Initiator times out waiting for second quick mode message.
1) Initiator re-sends first quick mode message.
2) Responder receives first quick mode message.
3) Responder sends second quick mode message.
4) Responder sets up new inbound SA. This is to handle the case
where the initiator starts transmitting on the new SA
immediately after sending the third quick mode message.
e) Packet is dropped during transmission.
1b) or 7b) Responder times out waiting for third quick mode
message.
1) or 3) Responder re-sends second quick mode message.
5) Initiator receives second quick mode message.
6) Initiator sends third quick mode message.
7) Initiator sets up new inbound SA.
e) Packet is dropped during transmission.
7b) Responder times out waiting for third quick mode message.
3) Responder re-sends second quick mode message.
5) Initiator receives second quick mode message again.
6) Initiator re-sends third quick mode message.
8) Responder receives third quick mode message.
and so on, as for normal operation.
IPSec Working Group [Page 11]
Internet Draft IPSec Re-keying Issues April 1999
2.2.1.3 Failed Negotiation
In this case, the second quick mode packet has an invalid hash, and
the initiator sends the notification to the peer. Again, the event
numbers refer to those illustrated in Figure 2-2.
1) Initiator sends first quick mode message.
2) Responder receives first quick mode message.
3) Responder sends second quick mode message.
4) Responder sets up new inbound SA. This is to handle the case
where the initiator starts transmitting on the new SA
immediately after sending the third quick mode message.
5) Initiator receives second quick mode message.
e) Hash (or other parameter) fails.
e1) Initiator sends notification to responder.
e2) Responder receives notification.
e3) Responder deletes new inbound SA.
A similar operation would occur if retry counters expire for packet
re-transmissions.
2.2.1.4 Responder Pre-Set Up Security Hole
In the failed negotiation case, the need to delete the invalid
inbound SA raises the issue of a temporary hole, in that the
responder allows inbound packets while waiting for the third quick
mode message. However, if the inbound SA is not set up ahead of
time, initiators that immediately transmit on the new outbound SA
will cause packets to be dropped.
It also illustrates why the proposal above made the usage of the
outbound SA by the initiator wait until there is an indication of
the use of the SA by the responder.
2.2.2 Recommended Re-keying Method
In this method, the previous method is modified to remove the risk
of the security hole. It also simplifies the operation somewhat, but
IPSec Working Group [Page 12]
Internet Draft IPSec Re-keying Issues April 1999
at the expense of lost packets if the initiator's behaviour is such
that it immediately uses the new SA for its outbound traffic.
Initiator Responder
Inbound Outbound Inbound Outbound
| | | |
1 ----------------- | |
| | ------------ | |
| | -------------------> 2
| | | | |
| | -------------------- 3
| | ------------ | |
4 <--------------- | |
| | | | |
5 ---------- | | |
| *6 ------------------ | |
| | | -------------------> 7
| | | | | |
| | | | | *
| | | | *8 |
| | | | | | *9
| | | | | *10 |
| | | | | |
| *11 | | | |
| | | *12 | | |
| | *13 | | | |
*14| | | | |
| | | *15 |
| | *16| |
| | | |
Figure 2-3 Recommended Phase 2 Re-key Sequence Chart
1) Initiator sends first quick mode message.
2) Responder receives first quick mode message.
3) Responder sends second quick mode message.
4) Initiator receives second quick mode message.
5) Initiator sends third quick mode message.
6) Initiator sets up new inbound SA.
7) Responder receives third quick mode message.
IPSec Working Group [Page 13]
Internet Draft IPSec Re-keying Issues April 1999
8) Responder set up new inbound SA.
9) Responder sets up new outbound SA.
10) Responder deletes old outbound SA.
11) Traffic from responder to initiator arrives at initiator on new
SA.
12) Initiator sets up new outbound SA.
13) Initiator deletes old outbound SA.
14) Initiator deletes old inbound SA.
15) Traffic from initiator to responder arrives at responder on new
SA.
16) Responder deletes old inbound SA.
Note that deletion of the old inbound SA by the initiator could be
further delayed if protection against loss of packets using the old
SA on different and slower network paths is desired.
2.2.2.1 Dropped Quick Mode 3 Message
In cases where the third quick mode message is dropped, the
responder must request re-transmission of it by re-sending the
second quick mode message. The existence of traffic on the new
inbound SA at the initiator should not be used as an implicit
acknowledgement for the following reasons:
1) There may be no traffic for the responder to send.
2) The responder may be designed to use the old SA until its
natural expiration.
This implies that implementations must be able to respond to the re-
transmission of the second quick mode message even after having sent
the third quick mode message.
2.2.2.2 Absence of Traffic
The proposed implementation uses the presence of traffic from the
responder on new SAs to provide an implied acknowledgement for the
IPSec Working Group [Page 14]
Internet Draft IPSec Re-keying Issues April 1999
purposes of switching to the new SA. However, if there is no traffic
from the responder, the implied acknowledgement will not appear.
A similar behaviour is exhibited by implementations that continue to
use old SAs until their natural expiration.
However, due to the number of implementations that delete old SAs 30
seconds after negotiating a new one, the same behaviour has the best
chance of interoperability, and of not dropping packets when traffic
does restart.
Therefore, it is recommended that implementations delete old SAs and
start using new SAs 30 seconds after negotiating new SAs in the
absence of traffic. Use of the DELETE notification is strongly
recommended in cases where the peer implementation is continuing to
use the old SA.
2.2.2.3 Compatibility With Observed Behaviours
When operating with behaviours that use the new SA immediately, this
method performs equivalently when this method is used by the
responder. When used by the initiator, the performance will depend
on when the responder deletes the old inbound SA.
When operating with behaviours that continue to use the old SA, this
method performs as described in the dropped quick mode three example
above when used by the initiator. When used by the responder, there
is no change in operation, since the responder will wait until the
new SA is used before deleting the old SA.
However, as stated in a previous section, it is recommended that the
initiator keep the old SA (both inbound and outbound) for only 30
seconds after creation of the new SA in cases where traffic is not
detected on the new SA.
2.2.2.4 Compatibility with Commit Bit
If the commit bit is set by the responder with this proposal, some
of the problems described in Section 2.1.4 may occur. To reduce the
effects of these problems, following rules should be followed:
1) The initiator should set up its inbound SA immediately after
sending the third quick mode message regardless of the state of
the commit bit.
IPSec Working Group [Page 15]
Internet Draft IPSec Re-keying Issues April 1999
2) Sensing of traffic on the initiator's new inbound SA should
trigger the use of the new outbound SA to detect cases when the
CONNECTED notification is dropped.
The recommended proposal does not allow built-in support of the
commit bit. It does allow responders that use the commit bit to
detect reception of the CONNECTED notification by the initiator due
to the presence of traffic on its new inbound SA. However, this
works only if there is traffic, so it cannot be considered a useful
method to perform this function.
The recommended proposal does cause the initiator to delay usage of
a new SA until it is set up. This is the primary use of the commit
bit, so use of this proposal makes the use of the commit bit
unnecessary except for the setting up of the first phase 2 SA.
2.2.2.5 Implementation Notes
The presence of traffic on the new SA can be part of the expiration
checking operation, and does not need to occur instantaneously,
although it must occur before the 30 second no traffic SA deletion
criteria. As long as the new SA is negotiated with enough time
before the expiration of the old one, the detection of traffic on
the new SA can be on the order of seconds with no ill effects.
Since SAs will likely have traffic counters anyway, this method
requires only the addition of a flag that indicates it is a new SA.
When the expiration process checks for ageing and expired SAs, it
can also check for new SAs with a non-zero traffic count. When
detected, the SA is marked as non-new, and the remaining operations
can be performed.
2.3 Conclusions
The final re-keying method is the best compromise for
interoperability within the framework of the current IPSec documents
without compromising security.
3. Phase 1 Re-keying
This section makes a proposal for main mode re-keying. This proposal
is necessary for many of the same reasons a phase 2 re-keying
proposal is necessary.
IPSec Working Group [Page 16]
Internet Draft IPSec Re-keying Issues April 1999
1) The rules for phase 1 re-keying are not specified in the
drafts.
2) Adhoc implementations have lead to poor implementations and
possible interoperability issues.
The goal of the proposed phase 1 re-keying method is to provide
secure, lossless communications. This means that there should be no
dropped traffic during re-keying, but also that there should be no
further traffic if re-keying fails.
3.1 Phase 1 Re-keying Requirements
The two reasons for re-keying a phase 1 SA are for freshness (time
or traffic) of the phase 1 keying material (affecting its ability to
protect phase 2 negotiations) and for re-authentication of the
encrypting devices.
This implies that there is no inherent need to delete phase 2 SAs
created by an expired phase 1 SA as long as there is another phase 1
SA available to verify the authentication of the peers.
Therefore, in order to re-key phase 1 SAs, it is recommended that
peers negotiate a new phase 1 SA before the old phase 1 SA expires,
at some percentage of the SA's lifetime.
Note that this automatic re-keying of phase 1 SAs means that SAs
could live independent of traffic, since re-keying of both phase 1
and phase 2 SAs takes place with no traffic triggers (if they expire
by time). In other words, SAs that are no longer necessary may never
disappear. If an implementation waits until traffic starts using
pre-existing phase 2 SAs before re-keying a phase 1 SA, that traffic
could be allowed to pass unauthenticated for the time that it takes
to negotiate. The difference between this case and the case of
immediately renegotiating is that the traffic could be flowing at
some arbitrary time after the phase 1 SA has expired (but before the
phase 2 SA has expired) and outside the authenticated time, while in
the other case, re-authentication of the SAs effectively happens
near the end of their authenticated lifetime.
This suggests that a traffic monitoring capability should be part of
implementations that need to delete idle or unused SAs. As such, it
is not given further consideration, since it is beyond the scope of
this document.
The existence of the INITIAL-CONTACT notification determines whether
it should delete any phase 2 SAs it has with the peer.
IPSec Working Group [Page 17]
Internet Draft IPSec Re-keying Issues April 1999
Summarised, the rules for phase 1 re-keying are:
Initial Phase 1 SA Negotiation:
-initiator MUST use INITIAL-CONTACT notification
-responder may use INITIAL-CONTACT notification
-responder deletes any pre-existing phase 1 SA with the peer when
authentication of peer complete
-responder deletes all previously existing phase 2 SAs with the
peer, if any
Phase 1 SA Ages:
-end point that first detects this negotiates new phase 1 SA;
becomes new initiator
New Phase 1 SA Negotiation:
-initiator MUST NOT use INITIAL-CONTACT notification
-responder MUST detect that this is a re-key and MUST NOT use
INITIAL-CONTACT notification
-responder SHOULD mark its existing phase 1 SA as re-keyed, so as
to not re-key again
-since no INITIAL-CONTACT notification is used by either end;
phase 2 SAs are kept
Phase 1 SA Expiration:
-DELETE notification SHOULD be sent for phase 1 SA only
Note that any information that may be associated with pre-existing
phase 1 SAs should be carried over into the new SA. Examples of this
type of information are addresses passed using the Configuration
Exchange mode.
3.1.1 Multiple SA Usage
When there is more than one phase 1 SA between peers, it is
recommended that the oldest SA be used for subsequent traffic
requiring phase 1 SAs. This allows full use of the keying material
generated and reduces race conditions. It also means that no special
expiration conditions are required when the phase 1 SAs expire by
traffic only, as the old SA will eventually expire on its own due to
usage.
3.1.2 INITIAL-CONTACT Notification
As stated above, the INITIAL-CONTACT notification should be used
only on the very first phase 1 that is negotiated between two peers.
IPSec Working Group [Page 18]
Internet Draft IPSec Re-keying Issues April 1999
If used on subsequent negotiations, it means that all pre-existing
SAs (phase 1 and phase 2) held between the peers should be deleted.
As an example, this is the mechanism used to detect when an SA end
point has crashed and is now alive again.
3.1.3 DELETE Notification
As currently defined by the IPSec documents, this notification is an
advisory only and is optional and unacknowledged.
Given that it is optional, UDP based, and not used by some existing
implementations, it should never be considered necessary.
However, even though its use is of dubious value, it SHOULD be sent
when any SA (phase 1 or phase 2) is deleted, since the expiration of
SAs may not occur at the same time at both ends to increase the
probability that both ends are synchronised with respect to SA
usage.
3.1.4 Re-keying Timing
To reduce the probability of simultaneous re-keying, each device
should re-key at a variable time with respect to the SA's expiration
limit, in case they are the same. These recommendations apply to
both phase 1 and phase 2 SAs.
An example of this is that the end with the higher IP address re-
keys at 95% of the lifetime, while the end with lower IP address re-
keys at 85% of the lifetime.
Whatever rule is chosen, it is recommended that the rule be
deterministic in order to have predictable and consistent behaviour
between peers. If the rule had used the SPI as the determining
factor (as an example did in the first version of this document),
different peers would be doing the re-keying at different times.
In any case, simultaneous attempts at re-keying should be supported
in one form or another, since it can never be guaranteed that this
will not happen.
4. Next IPSec Version Recommendations
The recommendations made in sections 2 and 3 of this document have
limitations in their ability to provide lossless, reliable and
IPSec Working Group [Page 19]
Internet Draft IPSec Re-keying Issues April 1999
interoperable SA re-keying due to restrictions of existing
implementations and the existing IPSec documentation.
This section makes recommendations for explicit re-transmission
rules, phase 1 and phase 2 re-keying, and introduces a new mode for
reliable SA deletion in order to better provide reliable, lossless
and interoperable re-keying.
Also, a replacement for the commit bit is proposed.
4.1 Re-transmission Rules
In systems that use an even number of exchanges, the rules for re-
transmission are relatively obvious. Simply put, a packet is re-sent
if the expected response to it is not received within a certain
period of time.
However, IPSec has a number of modes that have an odd number of
packets. This can lead to confusion as to when the re-transmission
rules should be applied. This in turn can lead to the dropping of
aggressive and quick modes' third messages. It is recommended that
each of these modes have specific rules applied to them to avoid re-
transmission issues.
These rules will be applied based on request-response pairs. Packets
are defined as a request or a response in an exchange. The requestor
is responsible for re-sending the request in order to solicit the
response. The responder (not to be confused with an SA negotiation
responder) is responsible for re-sending the response as it receives
the initial and subsequent transmissions of the request. Note that
the responder must exist after transmitting a response in case that
response is dropped.
In the modes with an odd number of packets, the request-response
pair must be applied across the odd number of packets. This means
that at least one packet must be considered the response to the
previous packet, and must also be considered the request of the next
request-response pair.
This means that an implementation must be able to perform re-
transmission of packets after it normally would have considered
itself to be done with an exchange or a mode. Further, any timers
set by the transmission of the final message of an exchange should
be reset when re-transmission occurs.
IPSec Working Group [Page 20]
Internet Draft IPSec Re-keying Issues April 1999
4.1.1 Main Mode Re-Transmission Rules
In main mode, there are effectively three completely separate
exchanges. The first request-response pair contains the SA
proposals, the second pair contains the keying material, and the
third pair contains the authentication material. (These descriptions
are generalised for the purposes of stating what the exchanges are,
and are not intended to create discussion on the actual contents of
the exchanges.)
As an example of the separation of the exchanges, there is no need
to resend the second main message to solicit the third main mode
message, since the responder should not send the fourth main mode
message until receiving the third main mode message. The absence of
the fourth main mode message will cause the initiator to resend the
third main mode message.
Keeping the exchanges separate from a re-transmission point of view
should simplify implementations.
4.1.2 Aggressive Mode Re-Transmission Rules
In aggressive mode, the second message is the message that is both a
response and a request. Therefore, the responder in a phase 1
negotiation that uses aggressive mode must re-transmit the second
aggressive mode message to solicit a third aggressive mode message
that it perceives as lost.
4.1.3 Quick Mode Re-Transmission Rules
In quick mode, the second message is the message that is both a
response and a request. Therefore, the responder in a phase 1
negotiation must re-transmit the second quick mode message to
solicit a third quick mode message that it perceives as lost.
These rules must apply independently of the state of the commit bit,
since there are currently no timing restrictions on the transmission
of the CONNECTED notification.
4.2 SA Delete Mode
The purpose of the SA Delete mode is to unambiguously delete SAs
used as pairs for phase 2 SAs, or a single SA for a phase 1 SA. It
is called a mode for syntactical consistency with quick mode, new
group mode and so on.
IPSec Working Group [Page 21]
Internet Draft IPSec Re-keying Issues April 1999
This mode consists of two packets, a delete request and a delete
acknowledgement.
The delete request's format is the same as the DELETE notification,
and may or may not refer to multiple phase 2 SAs or a single phase 1
SA. It is interpreted to mean the following:
"I am not sending anymore traffic on this SA (or these SA pairs).
Would you please stop sending traffic on it (or them), and send me
an delete acknowledgement when you are done?"
The receiver of the delete request then switches his outbound
traffic to another SA (the next oldest), deletes both inbound and
outbound SAs and sends the delete acknowledgement.
This is interpreted to mean:
"I am also not sending anymore traffic on this SA (or these SA
pairs). You may delete it (or them)."
The receiver of the delete acknowledgement may then delete the
inbound SA. The outbound SA should have already been deleted or
somehow not used before the sending of the delete request.
Note that re-transmission rules apply to the request-acknowledge
pair. That is, if the initiator of the delete mode does not get the
delete acknowledgement, the delete request should be re-transmitted.
Similarly, if the responder of the delete request receives multiple
copies, multiple copies of the delete acknowledgement should be
sent.
If the retry counter for the delete request expires, the SAs
indicated in the request should be unilaterally deleted.
Both messages must be sent encrypted under the protection of a phase
1 SA.
Note that there is a race condition for the delete request and
delete acknowledgement packets if an implementation sends them
immediately after sending a packet on one of the SAs to be deleted.
The race occurs if the packet order gets changed in the network and
the delete mode packets arrive before packets sent on the SAs to
which the deletes refer.
The delete request-acknowledgement pair should also be applied to
phase 1 SAs. In this case, the phase 1 SA is not completely torn
down until the reception of the delete acknowledgement message.
IPSec Working Group [Page 22]
Internet Draft IPSec Re-keying Issues April 1999
As a specific clarification, the binding between the inbound and the
outbound phase 2 SAs is not weakened. In the messages used, the SA
specified in the delete request is that of the sender's inbound SA.
In other words, the SPI sent to be deleted is the SPI that was
generated by the sender. This is simply to be consistent with the
format of the current delete notification. It may be more reasonable
to specify both inbound and outbound SPIs in the SA delete mode
messages.
When the delete mode is used to delete phase 1 SAs, the SPI values
used are the cookies of the phase 1 SA to be deleted.
The introduction of this mode does not eliminate the use for the
existing DELETE notification. It could still be used if an
implementation determines it needs to immediately (and impolitely)
delete an SA. Implementations must still recognise that it is sent
over UDP and may be dropped.
4.3 Phase 1 Re-keying for IPSecond
The phase 1 re-keying method described in Section 3 requires only
one change for IPSecond. That is the required use of the new delete
mode.
The Delete mode must be used in association with phase 1 when an
implementation intends to delete a phase 1 SA for any reason.
4.4 Phase 2 Re-keying for IPSecond
The phase 2 re-keying proposal described in Section 2, while
necessary under the circumstances, is not the ideal method of re-
keying. It forces the specific transfer times of SAs, thus making
the intent of paragraph 2, section 9 of [IKE] impossible.
This section describes proposals related to re-keying for the next
version of the IPSec protocols. The purpose is to precisely define
re-keying so that implementations are lossless and perfectly
interoperable during re-keying. It also allows the spirit of
paragraph 2, section 9 of [IKE] to be used. Further, it meets the
requirements of paragraph 3 of section 4.3 of [ISAKMP].
A summary of the recommendations is:
1) Define and require that the normal procedure is to use the
oldest phase 2 SA first, and to use it until its natural
expiration.
IPSec Working Group [Page 23]
Internet Draft IPSec Re-keying Issues April 1999
2) Use the recommended re-transmission request rules for quick
mode.
3) Make use of the delete mode a requirement.
4.4.1 Oldest Phase 2 SA First
The concept of using the oldest phase 2 SA first for outbound
traffic allows the maximum use of negotiated keys and allows for the
pre-negotiation of an arbitrary number of phase 2 SAs to be made
available for later use.
Additionally, it decouples new phase 2 SA negotiation from old phase
2 SA deletion, and the need to transfer to the new SA during re-
keying.
It also eliminates the race condition that occurs during SA set up
during re-keying. This means that use of the commit bit to avoid the
race condition is not necessary except when the very first phase 2
SA is set up.
The oldest SA is defined as the first negotiated of the available
SAs. In cases of simultaneous and near simultaneous SA negotiation,
the use of the delete mode and the ability to overlap SAs for an
arbitrary period of time should make this condition manageable.
4.4.2 Phase 2 Re-keying Illustration
This section illustrates the events when re-keying occurs using the
above proposals. Note the simplifications due to the decoupling of
SA negotiation and old SA deletion.
IPSec Working Group [Page 24]
Internet Draft IPSec Re-keying Issues April 1999
Initiator Responder
Inbound Outbound Inbound Outbound
| | | |
1 ----------------- | |
| | ------------ | |
| | -------------------> 2
| | | | |
| | -------------------- 3
| | ------------ | |
4 <--------------- | |
| | | | |
5 ---------------- | |
| *6 | ------------ | |
| | | ------------------> 7
| | | | |
| | | | *8 |
| | | | | |
9
| | | | | |
| | *10 *10 | | |
11 ----------------- | | | |
| | ------------ | | |
| | | -------------------> 12
| | | | | |
| | | | | *13 * 13
| | | | | |
| | | | | |
| | | -------------------- 14
| | ------------ *15| |
16 <--------------- | | |
| | | | |
*17| | | |
| | | |
Figure 4-1 Recommended IPSecond Phase 2 Re-key Sequence Chart,
Initiator Expiration
1) Initiator sends first quick mode message.
2) Responder receives first quick mode message.
3) Responder sends second quick mode message.
4) Initiator receives second quick mode message.
5) Initiator sends third quick mode message.
IPSec Working Group [Page 25]
Internet Draft IPSec Re-keying Issues April 1999
6) Initiator sets up new inbound SA. Implementations may choose to
set up the new outbound SA at this time, as long as they do not
use it.
7) Responder receives third quick mode message.
8) Responder set up new inbound SA. Implementations may choose to
set up the new outbound SA at this time, as long as they do not
use it.
9) Initiator's old SA pair expires.
10) Initiator starts using new outbound SA and stops using old
outbound SA.
11) Initiator sends first SA delete mode message.
12) Responder receives first SA delete mode message.
13) Responder sets up new outbound SA.
13) Responder deletes old outbound SA and starts using new outbound
SA.
14) Responder sends second SA delete mode message.
15) Responder deletes old inbound SA.
16) Initiator receives second SA delete mode message.
17) Initiator deletes old inbound SA.
If the responder's old SA expires first, the events are as follows.
IPSec Working Group [Page 26]
Internet Draft IPSec Re-keying Issues April 1999
Initiator Responder
Inbound Outbound Inbound Outbound
| | | | | |
9
| | | | | |
| | | | | *10 *10
| | | | | |
| | | -------------------< 11
| | | ------------ | | |
12 <--------------- | | |
| | | | | |
| | *13 *13 | | |
| | | | | |
| | | | | |
| | | | | |
14 >--------------- | | | |
15 * | ------------ | | |
| | -------------------> 16
| | | | |
| | 17 * | |
| | | |
Figure 4-2 Recommended IPSecond Phase 2 Re-key Sequence Chart,
Responder Expiration
9) Responder's old SA pair expires.
10) Responder starts using new outbound SA and stops using old
outbound SA.
11) Responder sends first SA delete mode message.
12) Initiator receives first SA delete mode message.
13) Initiator sets up new outbound SA.
13) Initiator deletes old outbound SA and starts using new outbound
SA.
14) Initiator sends second SA delete mode message.
15) Initiator deletes old inbound SA.
16) Responder receives second SA delete mode message.
17) Responder deletes old inbound SA.
IPSec Working Group [Page 27]
Internet Draft IPSec Re-keying Issues April 1999
4.5 Commit Bit Replacement
The intent of this section is to propose a mechanism to allow
implementations to delay the usage of negotiated SAs. Its use may
eliminate the need for the commit bit, and will not suffer from any
of the problems of the commit bit.
This is done by introducing a new mechanism to indicate to a peer
that usage of a newly negotiated SA should be deferred. Then,
depending on the deferral time intended, one of two mechanisms is
introduced to indicate that the SA may be used.
As this time, this proposal refers only to phase 2 SAs; however,
there is no reason the same concepts could not be applied to phase 1
SAs.
These mechanisms are preferred over the commit bit for the following
reasons:
o They receive the full protection of phase 1 SAs, and as such
provide the maximum resistance to denial of service attacks.
o Their use is clearly and unambiguously defined.
o They are resistant to the possibilities of dropped packets.
4.5.1 DEFER_USAGE Notification
The indication that an SA should not be made available for use
immediately can be indicated by the addition of a new notify payload
to the quick mode that negotiated the SA. To allow a single quick
mode to negotiate multiple SAs, the DEFER_USAGE notification
explicitly names the SA whose use is to be deferred, in the same
manner as the current DELETE notification.
The DEFER_USAGE notification payload should be added by the peer
wishing to delay usage of an SA.
On reception of the DEFER_USAGE notification, the newly negotiated
SA should be set aside until reception of the allow usage mode,
described in the next section, or the reception of the CONNECTED
notification.
The expected response depends on which type of DEFER_USAGE
notification is sent. These types are termed long and short. A short
DEFER_USAGE notification causes quick mode to become a for message
mode, as with the intended use of the commit bit. A long DEFER_USAGE
IPSec Working Group [Page 28]
Internet Draft IPSec Re-keying Issues April 1999
notification causes quick mode to proceed normally, with usage of
the specified SA deferred until the sender of the DEFER_USAGE
notification sends the first allow usage mode packet.
Implementations should be prepared to received the long DEFER_USAGE
notification for the same SA (pair) that they send it for; in other
words, usage of the both SAs of the negotiated pairs may be deferred
simultaneously by both peers.
There are no time constraints associated with the sending of the
long DEFER_USAGE notification and the subsequent reception of the
allow usage mode.
Usage of the short DEFER_USAGE notification is restricted to quick
mode responders only.
4.5.2 Allow Usage Mode
Like the delete mode, this exchange is called a mode for syntactical
consistency.
The purpose of this mode is to indicate to a peer that an SA may now
be used. Normally, usage of the SA by the peer would have been
deferred by the use of the long DEFER_USAGE notify payload,
described in the previous section. However, reception of this mode
for an SA whose usage has not been deferred is not considered an
error.
This mode consists of two packets. The first packet is an
ALLOW_USAGE notification. It specifies a previously negotiated SA
that may be used, and is similar to the delete request packet in
format.
The response packet to this packet is the
ALLOW_USAGE_ACKNOWLEDGEMENT notification.
The initiator of the exchange re-transmits the ALLOW_USAGE
notification until it receives the ALLOW_USAGE_ACKNOWLEDGEMENT
notification or exceeds its re-try counter.
The mode should always be sent under the protection of a phase 1 SA.
4.5.3 CONNECTED Notification
The intended use of the commit was to eliminate the race condition
that occurs at the end of a quick mode. In this context, the allow
IPSec Working Group [Page 29]
Internet Draft IPSec Re-keying Issues April 1999
usage mode adds more overhead than is necessary. Therefore, in this
case, the response to the DEFER_USAGE may be the
5. Acknowledgements
Some of the concepts presented in this document are based on work
done by TimeStep Corporation's engineering group.
Others are taken from concepts discussed within the IPSec working
group, particularly some of the concerns expressed about problems
with the commit bit.
6. References
[IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
RFC2409, November 1998
[ISAKMP]Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC2408, November 1998
Revision History
September 23, 1998 Initial Release
April 7, 1999 -clarification of objectives of document
-more commit bit comments
-change phase 1 re-keying discussion to explicitly
allow multiple phase 1 SAs between peers; previous
version explicitly allowed only 1 phase 1 between
peers
-other miscellaneous changes
Security Considerations
This document is associated with the IPSec family of documents. As
such, security considerations permeate the document.
IPSec Working Group [Page 30]
Internet Draft IPSec Re-keying Issues April 1999
Author's Address
Tim Jenkins
tjenkins@timestep.com
TimeStep Corporation
362 Terry Fox Drive
Kanata, ON
Canada
K2K 2P5
+1 (613) 599-3610
The IPSec working group can be contacted via the IPSec working
group's mailing list (ipsec@tis.com) or through its chairs:
IPSec Working Group [Page 31]
Internet Draft IPSec Re-keying Issues April 1999
Robert Moskowitz
rgm@icsa.net
International Computer Security Association
Theodore Y. Ts'o
tytso@MIT.EDU
Massachusetts Institute of Technology
This document expires October 14, 1999
IPSec Working Group [Page 32]