[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

minor editorial suggestions for draft-jenkins-ipsec-rekeying-06.txt



This document suggests minor editorial changes to
draft-jenkins-ipsec-rekeying-06.txt.

We currently intend to send two messages with more substantive
comments on the draft before the last call expires.

All notes are on lines starting with ">> ".

These notes are embedded in chunks of the original document to give
context.  Appropriate subsection headings are included to give context
to the context :-)


  Internet Engineering Task Force                             Tim Jenkins
  IP Security Working Group                               Catena Networks
  Internet Draft                                              May 3, 2000
 
 
                          IPsec Re-keying Issues
                   <draft-jenkins-ipsec-rekeying-06.txt>
 
 
     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC 2026.

  1. Introduction
 
     This document discusses issues associated with the use of protocols
     developed in the IETF's IPsec working group, specifically, RFC 2409
     [IKE] and RFC 2408 [ISAKMP]. It is expected that the reader is
     familiar with those documents.

>> Also draft-ietf-ipsec-ike-01.txt.
>> (Perhaps draft-ietf-ipsec-ike-hash-revised-00.txt?)
>> In the sequel, these will be refered to as the "IPsec documents".

     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
>>                                                          ^^^^^^^^^^is
     problematic, such that IPsec implementations can drop packets 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.

  2. Phase 2 SA Re-keying

     It also does not assume that the implementation has specific
     knowledge about the peer's behaviour. In other words, the peer's
     behaviour is assumed to be any of those that may be potentially
     allowed by the documents.
>>                 ^ IPsec

  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 explicitly defining how the transfer
         of traffic from old to new SAs is to be done.
 
     2)  The existing drafts appear contradictory in their
         recommendations on the usage of multiple phase 2 SAs.
 
     3)  Some implementations have shipped with a method of re-keying
>>                                              ^^      ^s
         that will not perform reliably under real world network
         conditions.
 
     4)  The use of the DELETE notification is not required.

>> Reword:
>>   4)  The DELETE notification is optional: an implentation need not
>>       send it and an implementation need not pay attention to it.
>>       Furthermore, a DELETE notification is not authenticated
>>       nor is it reliably delivered.

     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.

>> The Commit Bit is not authenticated.

 
     7)  A race condition exists at SA set up, exacerbating re-keying
         issues.

  2.1.1 Inconsistent SA Use Recommendation

     This interpretation of [ISAKMP] is in direct conflict with the usage
     implied by [IKE], resulting in potential problems.

>> This isn't clearly a contradiction.
>> SAs negotiated in one QM exchange are all the same age, there is no
>> newer/older distinction among them.

  2.1.2 Observed Behaviours

     All of these behaviours are permitted under the current documents.
>>                                                          ^ IPsec
  2.1.4 Commit Bit Interaction

     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 a
         number of possible denial of service attacks on IKE, this is
         not an excuse to leave the existing implementation as it is.

>> Alternate wording:

>> 3) The Commit bit is not authenticated, so a man-in-the-middle can
>>    modify it without detection.  The result would be a serious denial
>>    of service.

     Point 3 happens because the commit bit is in the ISAKMP header, and
     the ISAKMP header is not authenticated, so the commit bit is
     susceptible to undetectable modification.

>> This paragraph is now redundant.

  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.
>>                                                  ^ IPsec
  2.2.1.1 Normal Conditions

     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.

>> I think it would appear safer if 3) and 4) were reversed.

  2.2.2.1 Dropped Quick Mode 3 Message

     This implies that implementations must be able to respond to the re-
>>                     ^^^^^^^^^^^^^^^Initiators

     transmission of the second quick mode message even after having sent
     the third quick mode message.

  2.2.2.3 Compatibility With Observed Behaviours
 
     When responders use the proposed method and the initiator is an
     implementation that uses the new SA immediately, there is no
     difference in SA transfer performance compared to the responder also
     using the new SA immediately. This is because the proposed method
     tries to use the new SA immediately on inbound, so it will be ready
>>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>      immediately enables input on the new SA

     to receive on the new SA just as fast as an implementation that
     starts using the new immediately under all conditions. However,
     since the initiator is also using the new SA immediately, there is a
     possibility that packets will arrive at the responder on the new SA
     before the responder has time to set up the new SA.

  2.2.2.4 Compatibility with Commit Bit

     The recommended proposal does not allow built-in support of the
>>                                     ^^^^^^^^^^^^^^^^^^^^^^
>> What does this mean?

     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.

  3.1 Phase 1 SA Re-keying Requirements
 
     Two reasons for re-keying a phase 1 SA are for freshness (time or
     other) of the phase 1 SA keying material (affecting its ability to
     protect phase 2 SA negotiations and to generate phase keying
>>                                                        ^2

     material) and for re-authentication (and therefore authorisation) of
     the encrypting devices.

  3.3 A Note About Overlapping Phase 1 SAs

     A specific application for this model that provides distinct
     advantages is with the use of token cards. For example, if a userĘs
>>                                                                    ^'
>> [That character shows up as an AE dipthong on my xterm.]

     phase 1 authentication and authorisation is bound by the presence of
     a token card in a reader, the removal of the card should result in
     all SAs being torn down. Since there exists a continuous channel,
     delete notifications (acknowledged or not) can be sent for all SAs
     when the token card is removed from the system. However, if the
     phase 1 SA was allowed to be deleted without being re-keyed, the
     local end can only unilaterally delete its SAs, leaving the two end
     points out of sync with each other. (It cannot send delete
     notifications since the absence of the card makes it unable to re-
     establish a phase 1 SA.)

     Finally, it must be aware of implementations that do not want or
>>            ^^
>> What does "it" refer to?  "A system implementing the Continuous
>> Channel Model"?

     need phase 1 SAs that are continuously available.
 
 
  3.3.1 Identity Perfect Forward Secrecy
 
     Allowing the use of only a single phase 2 negotiation in a phase 1
     SA is how identity PFS is done. This is controlled by the deletion
>>                                           ^^^^^^^^^^accomplished
     of the phase 1 SA after a phase 2 negotiation.

>> Proposed replacement for first sentence:

>> Identity PFS requires that only a single Quick Mode negotiation
>> may be performed under the protection of a Phase 1 SA, and that
>> the Phase 1 SA must be destroyed after the negotiation.

     In implementations that do not wish to delete all phase 1 SAs, this
     can be done by creating two phase 1 SAs before the first phase 2
     negotiation is done. The first of these SAs is assigned the role of
     channel management, and thus performs SA deletion and notification
     transfer. The second SA is used to perform phase 2 negotiations, and
     is immediately deleted.

     Since Identity PFS is not negotiated, it may not be possible to
>>                         ^^^^^^^^^^^^^^neither negotiated nor announced

     guarantee that the peer knows Identity PFS is being used. In this
     case, the initiator may be required to delete its channel management
     SA and create a new one if the peer uses that phase 1 SA to re-key a
     phase 2 SA.

>> How does the peer find out about the deletion?

  4.1 Re-transmission Rules

     In the modes with an odd number of packets, the request-response
>>                        ^^^^^^^^^^^^^^^^^^^^^
>> For this to apply there must be more than one packet.
     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.

  4.2 Acknowledged SA Deletion

     Note that re-transmission rules apply to the request-acknowledge
     pair. That is, if the initiator of the delete mode does not get the
>>                                                 ^^^^ informational exchange
     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.

     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
>>              ^^^^informational exchange
     which the deletes refer.

     The use of the Acknowledged Informational does not eliminate the use
     for the existing DELETE notification. It could still be used if an
>>           ^^^^^^^^unacknowledged

     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.5.2 ALLOW_USAGE Notify Payload

     The initiator of the exchange must start usage of the inbound SA of
>>                                      ^^^^^^^^^^^^^^enable
     the pair when sending the first packet of the exchange. Usage of the
>>            ^^^^before
     initiator's outbound SA must wait until reception of the
     acknowledgement packet of the exchange.
 
     The responder of the exchange must start usage of its inbound SA of
>>                                      ^^^^^^^^^^^^^^enable
     the pair before sending the acknowledgement, and may start usage of
>>                                                              ^^^^^^^^using
     its outbound SA of the pair any time after receiving the first
     packet of the exchange.

Hugh Redelmeier
hugh@mimosa.com  voice: +1 416 482-8253