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

Re: ISAKMP commit and notify usage

I believe more needs to be said to clarify the need for Commit, and I
believe Dan H. is not right to say, that Commit is not necessary in phase I.

The strongest reason which demands use of Commit is, the possibility of
losing the final message of an exchange in the network.  ISAKMP is being
used at the UDP layer and so has no protections against loss except its own
prescription for retransmissions.  The party who sends the final message
has no indication that the message was lost and retransmission is required,
particularly for the case where that party is going to send the first
message afterward.

A party sending the last message of Phase I, will sometimes have a Phase II
initiation which they are going to send immediately after.  But this should
wait until the party receives confirmation from the other side.

At 12:09 PM 5/12/97 -0700, Daniel Harkins <dharkins@cisco.com> wrote:
>  Hi Tom,
>
>> I am trying to understand the usage of the ISAKMP commit bit flag and
>> notify messages.
>> 
>> The ISAKMP header contains a flags field which contains a commit bit. When
>> set by the sender this tells the peer ISAKMP not to use the (ISAKMP or
>> IPSEC ?) SA until the sender transmits an informational exchange.
>> Subsection 4.8 of the ISAKMP spec - Informational Exchange - states that
>> once an ISAKMP SA has been established, the Informational Exchange MUST be
>> transmitted under the protection provided by the ISAKMP SA.
>> 
>>  - Does this prevent use of the encryption key/SA by ISAKMP or only IPSEC?
>
>  It prevents use of the IPsec SAs. It wouldn't make sense to use this for
>phase 1 and, in fact, I would interpret receipt of this bit in phase 1 to
>be intended for the forthcoming phase 2 exchange.

I would disagree that Commit is unnecessary in Phase I, per what I discuss
above.

>  The point of this bit is that a Quick Mode exchange (from the ISAKMP+Oakley
>doc) is a 3 message exchange and upon receipt of the responder's only 
>message, the initiator has all the information necessary to stuff the IPsec
>SAs into its SA table. If this is done before the final message is composed
>(a hash from initiator to responder) there is a possibility of that SA
>being used by the kernel (or IPsec process or whatever depending on your OS 
>flavor). If the timing is right (or wrong I guess) valid IPsec packets could 
>arrive at the responder before hash which completed the exchange and allowed 
>the responder to stuff the SAs in its own SA table. These packets would be
>dropped.

While it is okay that one designs protocol which makes it easier to work
within the current operating systems, still such problems as Dan describes
above actually constitute bugs in implementation either of the operating
system or of the ISAKMP.  One cannot hope to use net protocol design to fix
all the bugs in various implementations.

It is necessary however that protocol deal with the hostile net
environments in which the user public generally will be operating, and
assuming that all messages can be lost is one of the basics which net
protocols must cover.

>  If the COMMIT bit was set by either party, the Quick Mode exchange would
>become a 4 message exchange and the initiator would not stuff its SAs 
>until receipt of the notify message. The responder would stuff its SAs first.
>Yes, this would make it ready for use before the intiator was ready but
>since the initiator started this its got some packets queued up and waiting
>to be sent. It's unlikely that the responder also has packets queued up and
>waiting, it could, but it's just unlikely. The timing would have to be real 
>horrible (and the SA would have to be sharable-- no PFS) for the responder
to 
>use the SA before the initiator was ready.
>
>  Anyway, I personally don't see this as a big problem and haven't had any 
>trouble using ISAKMP and IPsec without the COMMIT bit.

The fact that one hasn't had trouble at this point of experience in ISAKMP
protocol does not strike me as evidence that protections are not needed.
Some network environments are much more hostile than others and protocol
design is supposed to deal with it.  Cylink intends to take that line in
its implementation.

>
  [ other things: fine.]

>  regards,
>
>    Dan.

A further problem in the ISAKMP draft: it prescribes retransmissions even
for the final message, but discusses no way in which one can be provoked to
retransmit a final message.  I think the following considerations are
necessary.

The final message can always be lost, even if it is the "Connected"
message.  The party who expects to receive the final message would in that
case receive instead the encrypted traffic which follows (for the case of
completing Phase I, read, a Phase II initiation).

Now if the party was awaiting the "Connected" message, AND the received
message can be verified as correct, they can assume the other party
completed the SA.

In all other cases the only action one can take here is, to retransmit the
last ISAKMP message one sent, trying to provoke the partner to retransmit
the final message.

This implies that, if you are the party sending the final message, then you
should retain that message for a while, with the SA establishment
last-state; it can be saved in LRU buffers, and it can be discarded when
you get evidence the partner has established the SA.

Best regards,
John Burke
Cylink, Sunnyvale, CA.