RE: AggressiveMode issue

[Tero Kivinen <[e-mail]>]

Roy Pereira writes:
> The problem with this approach is that an implementation would have to
> hold every ISAKMP message sent in a retransmission buffer.  That is
> quite costly for a security gateway handling thousands of connections.

You have to store the last packet you sent out, not all packets in the
exchange. Note that quick mode if different exchange so its packets
are not part of the main mode exchange and they must not overwrite the
last sent main mode packet. 

The last packet of the exchange (both main mode and aggressive mode)
must be stored for (retransmit timer * retransmit count) seconds (so
if you have 2 second retransmit timer and 3 retransmits you have to
keep information needed for retransmission for 6 seconds). This last
packet of the exchange needs only be kept in that end that is sending
the final packet. 

For example the responder of the main mode must keep the last packet
sent to initiator for that time, or until it receives first packet
using already created isakmp sa. 

> Perhaps a better way is to use the COMMIT bit to require a
> NOTIFY-CONNECT message to be sent the the responder, then proceeding
> with the QuickMode exchange?

That would help for the last packet of the aggressive mode for the
initiator, but it doesn't help any other cases, so you still must be
able to retransmit also that notify connect packet. 

Lets take an example to calculate the cost of storing last sent
packet:

	- gateway server with hardware acceleator that can do 10 * 10
	  diffie-hellmans / second (100 milliseconds / diffie-hellman,
	  10 paralleal units). 
	- PC-client that takes about 500 milliseconds /
	  diffie-hellman (group 1).
	- round trip time 300 milliseconds.

Minimum time main mode exchange takes 100 ms + 6 * 300 ms + 500 ms =
2400 ms. The retransmit timer must be more than 500 ms + 300 ms,
because otherwise the PC cannot reply fast enough, so lets say it is 3
seconds (say we can have very slow clients too). Lets assume the
maximum number of retransmits is 5.

The server can start 100 new negotiation / second. The maximum
retransmit time is 3 * 5 seconds = 15 seconds. So you have to store
the last packet of the (2.4 + 15 * 100) = 1740 negotiation. Lets say
you allocate 1 kB packet for that (the packet containing the
certificate might take about 1 kB, so we are really assuming worst
case). This means your server must allocate 1.8 MB of memory for those
retransmit buffers.

If you add in the scenario that 10% of all packets is dropped you
get the average negotiation time for about 5 seconds, so the memory
requirements goes from 1.8 MB to 2.0 MB.

That is not much, if you keep in mind that, that server is able to
handle 360 000 clients having 1 hour rekey time, or 2 880 000 clients
having 8 hour rekey time.

If your clients are using blowfish your server must be able to store
1430 MB of key schedule information (each blowfish key schedule
context is about 4 kB).

I think storing the last sent packet for each ongoing exchange is not
too expensive. Of course you want to store also the last received
packet so you immediately notice when the other end retransmits and
send your previous packet back. So that doubles the memory
requirements. 
-- 
[e-mail]                               Work : [phone]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/