Software is like entropy. It is difficult to grasp, weighs nothing, and obeys the Second Law of Thermodynamics, i.e., it always increases.
Norman R. Augustine, Augustines Laws, Law Number XVII The IPsec standards generally specify packet formats and other observable details that affect Internet traffic. Numerous other details are often labeled implementation-specific and left to the discretion of the individual imple-menters. Sometimes, suggested behavior, or best common practice, is defined in an informational RFC. Many times, implementation details are not discussed at all, even though they can decidedly affect interoperability of multiple implementations. A number of such details either were omitted from the original IKE documents or were underspecified. Day-to-day opera-tional experience with IKE highlighted the need for standardization or clari-fication of such features, including SA renegotiation, ISAKMP heartbeats, and dangling SAs. These features are all somewhat controversial, and it is not clear which will remain for the long haul and which will be consigned to the dustbin of digital history.
153
7.1 Renegotiation
The timing of IKE renegotiations is an operational detail that can seriously degrade network communications between two implementations that imple-ment it in different ways, even if both conform to the IKE specifications [1].
Most implementations do not wait for an IPsec SA to expire; it is com-mon practice to initiate renegotiation at some interval, either time based or traffic based, prior to expiration. The interval is generally a random one, because predictable behavior is the Achilles heel of security.
One question remains: When should an initiating peer begin using the newly negotiated outbound SA, and when should the receiving peer stop accepting traffic on the about-to-expire inbound SA? There are two schools of thought. The first school advocates using up the old SA and not using the new SA until the old one has actually expired; the second suggests switch-ing over to the new SA as soon as it is in place, without worryswitch-ing that the old SA has not been totally exploited. The cautious approach, which enables interoperability with both schools, leaves three of the four SAs (the old and new inbound SAs and the new outbound SA) in place as long as possible.
Outbound traffic, which is under the control of the sender, is sent on the new SA, just in case the peer has deleted the old one. Inbound traffic, over which the recipient does not have control, is accepted on the old SA, which is not deleted until inbound traffic has been received that uses the new SA; it also is accepted on the new inbound SA.
In any IKE exchange, one peer assumes the role of initiator and the other the role of responder. However, in any subsequent IKE exchange, the roles can be reversed. That applies to a phase 2 negotiation that follows a phase 1, or to a phase 1 exchange that renegotiates an about-to-expire phase 1 SA or any other IKE negotiation.
Therenegotiationorrekeyingof an IPsec SA is triggered by the end of the SAs lifetime as measured in elapsed time or number of kilobytes of data protected by the SA. Although a new SA must be negotiated, including the complete set of SA parameters, the process is often referred to as rekeying, because it is the exposure of the secret keys that motivates the SA renego-tiation. Too much elapsed time since the SA negotiation or too much data encrypted by the encryption key can provide enough time and ammunition for a variety of attacks aimed at discovering the secret key. If the ISAKMP SA through which the IPsec SA was negotiated is still alive, it can again be used to negotiate the IPsec SAs successor, and only a phase 2 negotiation takes place. If the ISAKMP SA has also expired, a full-blown two-phase negotia-tion must again occur.
One of the problems that bedevils IKE in a number of different con-texts is its reliance on an unreliable transport protocol, UDP. That means reliance on the delivery of different messages in a prespecified order can and will result in problems. Thus, the specifications must always anticipate these race conditionsand dictate IKEs behavior under alternative conditions. One race condition that pertains to rekeying is the timing of the responders reception of the final phase 2 message relative to receiving the first incoming message protected by the new SA. Figure 7.1 demonstrates this problem.
Assume that host H1 is the initiator of the phase 2 negotiation. If H1 is a high-powered machine and can encrypt that first message rapidly, and if the two messages traverse different paths to reach the responder, H2, then the encrypted message can arrive at H2 before the final phase 2 message.
Because that final message does not contribute any new information to the SA, and because H2 can calculate the key before it sends the second phase 2 message, this scenario can have a happy ending, with protected com-munications exchanged in either case. But that does involve some flexibility on the part of the responder, which has to be prepared to accept and process the packet that relies on the new SA before the SA negotiation has formally concluded. It also leaves the responder open to a replay attack, because the third message, in which the initiator computes an authenticated hash that includes the responders nonce, constitutes proof that this is not a replayed negotiation. In the event that this is a replay attack, it could disrupt commu-nications between H1 and H2. H2 would be convinced that a new pair of SAs had been established with H1; the keying material would be calculated from the replayed initiators nonce and H2s newly generated responders nonce. When H2 would send outbound traffic on the bogus outbound SA,
Quick Mode Message #1 1
4
5 Quick Mode Message #2
2
Set up New SA (I-to-R)
3Initiator ResponderQuick ModeMessage
#3 Trafficon
New SA(I-to-R) Figure 7.1 Rekeying race condition.
that traffic would be rejected by H1, because H1 had not negotiated the new SA. Obviously, H2 would not receive inbound messages from H1 using this SA. Any inbound messages would have to be sent by the attacker, which would replay genuine messages that had been sent to H2 by H1. Those messages would be protected with the keying material from the old SA, so they would be rejected by H2. The result would be a disruption of commu-nications from H2 to H1 and wasted processing performed by H2.
Figure 7.2 shows a suggested sequence of Quick Mode negotiation, illustrating the order of SA activation and deletion relative to the launch or arrival of each Quick Mode message. The order was selected to maxi-mize interoperability and security and to minimaxi-mize dropped packets. The responder has the option of activating the new inbound SA either before or after the third Quick Mode message has been received. Each approach has its pluses and minuses. The earlier SA activation allows a smooth transition to the new inbound SA, even if the third Quick Mode message is lost or delayed. If the first Quick Mode message is a replayed message, or if there is a problem with the second Quick Mode message (e.g., an incorrect authenti-cating hash), the new inbound SA is invalid; if the responder then deletes the old inbound SA, inbound packets are dropped. The initiator will still be
Set up SA #2 (R-to-I)
5
Quick Mode Message #1 1
Quick Mode Message #3 4
Quick Mode Message #2
2
Traffic on SA #2 OR No Traffic for 30 seconds
9
Set up SA #1 (I-to-R) 3
Set up SA #1 (I-to-R) Set up SA #2 (R-to-I) Delete Old SA (R-to-I)
687
Set up SA #1 (I-to-R)
Delete Old SA (R-to-I) Delete Old SA (I-to-R)
Initiator Responder
101112
Figure 7.2 Quick Mode rekeying order of operations.
using the old SA, which was deleted by the responder; the responder will be expecting packets to use the new, invalid SA. The later SA activation avoids those pitfalls, but it opens up the possibility that the responder would receive traffic protected by the new SA before receiving the third Quick Mode message and, therefore, before activating the new inbound SA. That causes a (temporary, we hope) black hole, resulting in a cessation of inbound traffic until the third Quick Mode message is received.
7.2 Heartbeats
What happens when a busy gateway or a host that sends most or all of its traffic under the IPsec umbrella negotiates a large number of IPsec SAs?
Some of them will be used regularly, but some will be used once or twice to fulfill a specific transaction and then sit idle until they expire. In the event that an SA was foolishly negotiated to expire only on traffic volume and not on elapsed time, it may never expire. Unused SAs can cause clutter, at best, or, in the case of a malicious peer, they can contribute to a denial-of-service attack. For those reasons, some implementations delete SAs that are unused for a specific time, even if they have not yet expired.
Another possible cause for the termination of an unexpired SA is the unexpected shutdown of a host system, either as the result of a system crash or, for a road warrior, a phone hangup. When the system reappears, it can send an initial contact message, so that the peer deletes all previously negoti-ated SAs. Until that happens (if it happens), the peer that neither crashed nor deleted dormant SAs assumes that those SAs are still operative and blithely sends outgoing traffic that relies on them. That can result in considerable wasted processing and lost communications.
To handle that problem, a new mechanism, originally called a keep-alivebut now referred to as aheartbeat[2], has been defined. A heartbeat is a one-way message sent at periodic intervals that notifies the recipient that its peer is still alive. The message can optionally include the SPIs of some or all of the existing outbound SAs between the sender and the recipient, as a sanity check for the recipient.
The negotiation to set up a heartbeat is a configuration method exchange that takes place under the protection of an existing ISAKMP SA.
It is always initiated by the intended recipient of the heartbeats. That allows the recipient to dictate the behavior and timing of the heartbeat messages, subject to the agreement of the sender. If both peers require this type of assurance, two separate heartbeat negotiations can take place. Because the
heartbeat is used to prove the continued health of the system as a whole, even if multiple SAs exist between two peers, the maximum number of heart-beat negotiations that would be required is two, one in each direction. Five attributes can be negotiated.
• Heartbeat type. Only a single, standard type is currently defined.
This attribute can be used to extend the protocol in the future or to agree privately on a different mechanism.
• Heartbeat options. The options are used to negotiate the support of optional behavior. Generally, heartbeat messages are encrypted and authenticated, but the authentication only option can be used to negotiate a heartbeat message that will be authenticated but not encrypted. If the recipient does not propose this option, the sender should not downgrade security by suggesting its use. The SPI list supported option allows the sender to include an optional SPI list, detailing some or all of the SPIs in effect between the peers, in some or all of the heartbeat messages. If the recipient does not propose the use of this option, it would be wasteful for the sender to suggest it, knowing that the recipient most likely will just discard the information.
• Heartbeat interval. The interval is the number of seconds between heartbeat messages. The suggested default value is 20 seconds. If the heartbeats recipient proposes a heartbeat interval, the sender is allowed to increase the interval to send fewer heartbeats and thus consume less processing power.
• Heartbeat message accepted. This attribute is used by the heartbeat negotiation responder (who will be the sender of the heartbeat mes-sages themselves) to either agree or refuse to initiate the heartbeat message mechanism.
• Initial sequence number. This attribute is the sequence number to be sent in the first heartbeat message.
Figures 7.3 and 7.4 show two sample heartbeat negotiations, one in which the responder sets the parameters that will govern the heartbeat message and one in which the values are proposed by the initiator.
Once the heartbeat message has been negotiated, the sender can start sending heartbeats, which consist of regular ISAKMP messages with a new exchange type: Heartbeat Exchange Mode. Figure 7.5 shows the payloads
REQUEST
(HEARTBEAT_TYPE Standard,= HEARTBEAT_INTERVAL 20,= SEQUENCE_NUMBER 1111,= HRTBEAT_OPTIONS Send SPI List)=
1
REPLY
(HEARTBEAT_TYPE Standard,= HEARTBEAT_INTERVAL 40,= SEQUENCE_NUMBER 1111,= HRTBEAT_OPTIONS Send SPI List,= PROPOSAL_ACCEPTED 1)=
2
Initiator Responder
Figure 7.4 Heartbeat negotiation with parameters proposed by the initiator.
REQUEST
(HEARTBEAT_TYPE Standard)= 1 REPLY
(HEARTBEAT_TYPE Standard,= HEARTBEAT_INTERVAL 20,= SEQUENCE_NUMBER 1111,= PROPOSAL_ACCEPTED 1)=
2Initiator Responder
Figure 7.3 Heartbeat negotiation with parameters set by the responder.
HDR, {SEQ_NO, HASH, NOTIFY, [SPI_LIST]}
1
Initiator Responder
Figure 7.5 Heartbeat payloads.
sent in a typical heartbeat message. Two new payloads were defined for the heartbeat message.
• Sequence number payloadcontains the heartbeats sequence number, used for replay protection.
• SPI list payloadcontains a full or partial list of the SPIs of the out-bound SAs that currently are in place between the sender and the recipient.
The notify payload contains a special informational message, notify still connected. The hash payload contains the authenticating hash, a keyed hash of the complete message with SKEYID_a as the key. To authenticate the complete message, the hash input consists of three parts.
• The ISAKMP header and the message payloads that precede the hash payload;
• A hash payload, consisting of the generic payload header with a zero hash value;
• The message payloads that follow the hash payload.
Figure 7.6 shows the authenticating hash for the message shown in Figure 7.5.
When the recipient gets a heartbeat message, it first verifies the authen-ticating hash to ensure that the message is legitimate. It then examines the sequence number and performs replay checking by comparing it with the last sequence number received, in the same manner that is done by IPsec. If the replay check succeeds, the current sequence number is updated; if the pack-ets sequence number lies outside the current replay window and the replay check fails, the heartbeat packet is ignored. Generally, the ISAKMP SA
Hash Keyed HMAC of HDR,= SEQ_NO, HASH_0, NOTIFY, SPI_LIST
With Key SKEYID_a= Figure 7.6 Heartbeats message hash calculation.
is renegotiated before the sequence number reaches the maximum possible value. If it does reach that value, however, the heartbeat messages must cease, because there is no way to distinguish a heartbeat with a restarted low value from the replay of a previous heartbeat message.
Once the predetermined interval passes without receiving a heartbeat, the recipient can assume that the sender is now incommunicado and can delete the ISAKMP SA, along with its subsidiary IPsec SAs. If the sender decides to delete the ISAKMP SA, thus halting the heartbeats as well, the recipient should be notified of the deletion in a reliable manner, either through the use of an acknowledged informational message or by repeatedly sending the delete message to maximize the possibility that it will be received.
Other relevant metrics are determined or recorded by the heartbeats
recipient.
• Lost packet tolerance. The number of lost heartbeats that can be toler-ated before the peer is considered to be dead. The suggested default value is 3.
• Packet transmission window. The maximum number of seconds required from heartbeat message origination by the sender until acceptance by the recipient, including travel time. The suggested default value is 5 seconds.
• Timeout interval. The number of seconds since the last heartbeat message considered to signify the peers death. The suggested default value, based on a heartbeat interval of 20 seconds, is 65 seconds, using the formula
Timeout interval=
(heartbeat interval∗lost packet tolerance)+ packet transmission window
• Last good sequence number. Last sequence number received in a valid heartbeat message.
• Sequence number window. The size of the replay window, that is, the maximum allowable deviation in sequence number for two consecu-tive heartbeat packets.
If the SPI list option is supported, it can be sent in each heartbeat mes-sage or periodically every few mesmes-sages. In addition to the SPIs themselves,
the SPI list payload contains two special values: the minimum SPI contained in the list and the maximum SPI. That serves two purposes: It helps the recipient to process the SPIs more efficiently, and it enables the SPIs to be distributed among multiple SPI payloads or multiple heartbeat messages.
Thus, if the peers share a large number of SAs, each heartbeat message does not have to carry that heavy baggage. The recipient of the SA payload should examine all inbound SAs established with the peer and delete any SAs from the SAD whose SPIs fall within the minimum-maximum bound but do not appear in the payloads list of SPIs.
Because the heartbeats are sent under the protection of the ISAKMP SA, a new heartbeat negotiation must take place each time the ISAKMP SA is renegotiated.
What types of attacks are the heartbeat packets designed to avoid? The sequence number protects the recipient from replay attacks, and the authen-ticated hash protects against spoofed packets. That prevents replayed and spoofed packets from presenting false proofs of liveness once a machine has gone down. In addition, unauthenticated notify messages (e.g., deletes) that contradict the SPI list in a current heartbeat message can be ignored and assumed to be bogus. Some types of attacks cannot be avoided. If heartbeat packets are prevented from reaching the recipient, and the recipient mis-takenly deletes still-current SAs, that constitutes at least a temporary denial of service. If the heartbeat packets are authenticated but not encrypted, and the SPI list option is selected, the SPIs are sent in the clear, exposing that sensitive information to eavesdroppers.
7.3 Initial Contact
Then there is the opposite problem. What happens when one peer disappears for a while? That can happen as the result of an unplanned reboot or, for a road warrior, an unplanned disconnect. When the unfortunate system resur-faces, it may have lost all its SAs and have to start negotiating new ones. Its communicating peers, however, still think the old SAs are valid. When the newly reborn peer begins a phase 1 negotiation, it should include an initial contact [3] notification message in its first ISAKMP message. That notifies the peer that this is not a renegotiation of an existing SA but rather a new start, and any SAs with this peer that are still intact should be deleted.
7.4 Dangling SAs
What happens when a phase 1 SA expires or is deleted as a result of a delete notification? In particular, should the phase 2 SAs that were negotiated
What happens when a phase 1 SA expires or is deleted as a result of a delete notification? In particular, should the phase 2 SAs that were negotiated