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

RE: ISAKMP commit bit and connected notifications

The commit bit is mainly there for implementations that cannot handle
dropped packets or out-of-order IKE/IPSec packets (i.e., system receives
IPSec packet for an SA when the 3rd QM message for that SA was dropped or
isn't processed yet).

The Commit bit is one option for how an implementation can deal with this
dropped packet/out-of-order packet scenario.

An alternative to using the commit bit is given in Section 3.1 of RFC2408
(ISAKMP) in the NOTE: under the Commit Bit paragraph where it suggests that
a properly authenticated IPSec packet can in effect take the place of the
missing 3rd QM message.

I'd love to see the commit bit go away even at the expense of the "Quick
Mode" always being 4 messages (for those implementations that preferred the
commit bit option for handling the situation described above). A 4 message
Phase 2 exchange would allow for the added benefit of DH group negotiation.

Another option that at least one implementation uses (which thankfully isn't
recommended by any RFC) is to send out several copies of the 3rd QM message.
This might help the dropped packet situation somewhat but doesn't do
anything to help the out-of-order packet situation and I would recommend
strongly against using this option.

-dave

-----Original Message-----
From: sami.vaarala@netseal.com [mailto:sami.vaarala@netseal.com]
Sent: Tuesday, March 28, 2000 5:48 AM
To: ipsec@lists.tislabs.com
Subject: ISAKMP commit bit and connected notifications



Sorry for bringing this up yet again,

Can anyone give a solid reasoning as to WHY we need commit bit or
connected notifications at all?  As far as I can tell, a connected
notification does not guarantee a consistent outcome of an exchange
any more than an exchange without a connected notification.

The "three army" problem seems to apply:
  - if the last message IS critical to the consistent completion, it
    must not be dropped or otherwise the exchange fails to complete
    consistently
    [if not, this message is not critical after all, right?]
  - on the other hand, if the message is not critical, we can remove
    the message from the exchange.
  - continuing this way, we end up in a situation where the last message
    is critical [for IKE, connected notifications are non-critical].
    Yet, we cannot guarantee its delivery (by the very nature of IP).

As far as I can see, the best (only?) solution is to keep connection
state for a while after sending the last message.  If a duplicate of a
previous message arrives, resend the last message.  Keep doing this for
some sane timeout value (e.g. 3*round-trip), perhaps applying a sanity
rate limiter to avoid flood attacks. This guarantees consistent
completion to a certain probability (not 100%), which you can tune by
choosing an appropriate timeout value.

(The same reasoning applies to e.g. TCP connection teardown; there is
no 100% guaranteed way of tearing down a TCP connection and TCP uses a
similar timeout strategy.)

Do others agree with this reasoning?  If so, I suggest the following:
    - deprecate the commit bit from ISAKMP (or the IKE exchanges)
    - add wordage about proper behavior wrt last exchange message
      (encourage a behavior that works robustly) to either ISAKMP or
      IKE spec
    - acknowledged notifications should mandate this last message
      behavior (otherwise they aren't any more guaranteed than normal
      notifications)
    - normal notifications cannot benefit from the last message strategy
      because there is only one message to send; wordage about this
      should be added to clarify the difference between acknowledged
      notifications

This is a "phase out" strategy; older implementations may continue to
support commit bit but newer ones should not mandate commit bit
processing.

--
Sami Vaarala (sami.vaarala@netseal.com)
NetSeal Technologies
http://www.netseal.com/