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

Clarification on ISAKMP Commit-Bit

We would like a little authoritative clarification on the use of the Commit
bit.

I understand from the draft that support for receiving Commit is required
in all the Session Establishment exchanges. We see reason to use Commit in
all exchanges, as I discuss below.  Also some quick questions.

Question: I suppose it's correct to set the Commit bit on only the final
message I send.

Question: I suppose I can ignore a Commit bit in all messages received
except the final one.

Presumption: I presume it's wrong for me to set the Commit bit in an
exchange where I am not going to send the final message, and the other end
could give me "invalid flags".

Now, the question that bears discussion:

The ISAKMP draft is vague about exactly why anyone might choose to set the
Commit bit, and permissive about when one could expect it.

As I remember in discussion on this point on this mail list, a couple of
individuals expressed their particular reason for finding Commit useful,
and some seemed to be suggesting that there is no other reasonable use,
implying I suppose that one need not support it in other exchanges?

As best I remember, people put forth a scenario somewhat like this (don't
have the original so can't vouch for accuracy):

  o In Aggressive Mode, the Initiator receives the first response, which
    includes KE; at this point Initiator can complete generating the ISAKMP
    SA session keys.

  o Initiator makes the final message, with Hash; it does not want this
    message encrypted.  It sends the message out the socket to the kernel.

  o Initiator wants to stuff the keys down the PF Keys socket; the result of
    this will be the kernel will start encrypting for the ID pair.

    BUT: the daemon cannot find out whether the enqueued Hash message has
    gotten to IP output yet, so it cannot tell when it's okay to stuff in
    the keys.

  o By setting Commit, the Initiator demands the Notify from the Responder,
    and can wait for it before stuffing the keys.

But I saw another consideration making Commit useful, and it makes sense in
all the session establishment Exchanges:

  o The party who sends the last message of the exchange, would like
    assurance the final message arrives and is accepted.

    This can apply to all the exchanges: to Initiator in Quick or
    Aggressive mode and to Responder in Main Mode.  In all cases it is
    possible that the first traffic to go out after the exchange is
    complete, can originate with the party who sent the final exchange
    message.

    Without this assurance, the sender of the final message can perform
    encryption on the message to follow and wind up throwing it down a hole
    because the other didn't get the final message and cannot complete the
    SA; recovery from this is a dirty business.

  o If the sender of the final exchange message sets Commit, then there
    will be positive assurance the final message arrived and the SA is
    established on both sides.

    The sender now has a basis to time out and retransmit the final
    message.

    If the Notify(Connected) gets lost but the Responder sends encrypted
    data right after it, the Initiator system has these choices:

      o Retransmit the final message, AND/OR:

      o Recognize that the SA is already (provisionally) established; if
        the message can be authenticated, then mark the SA as fully
        established.

- John Burke