Re: Ready for IETF Last Call draft-ietf-ipsec-dpd-01.txt

["Andrew Krywaniuk" <askrywan@hotmail.com>]

I have some long-standing comments on the DPD draft, seeing as it is 
apparently being updated anyway.

The justification for why DPD scales better than heartbeats still bugs me. 
You quote this sensationalistic number of 50,000 IKE packets every  few 
seconds, which is meaningless (the same concentrator is no doubt forwarding 
tens of millions of packets during that same interval).

Still, the DPD draft does vastly reduce IKE bandwidth. But I don't see any 
mention of the tradeoff, which is response time. The schemes with periodic 
messages send most of those messages in order to ensure that an idle SA will 
work when needed. The DPD draft saves bandwidth by not probing an idle SA, 
but when a broken SA is discovered, the fault is corrected pre-emptively. 
That is the salient tradeoff in this case.

On another note, the sequence number scheme is similar to what I defined in 
draft-heartbeats, but I think you are misapplying it. In the case of 
heartbeats, I had a good justification for requiring that the sequence 
number increases by exactly 1 each time. The heartbeats were unidirectional, 
and there were certain subtle attacks that could only be prevented by strong 
binding the sequence number to time.

That situation doesn't exist here. The sequence number still prevents 
replay, but it doesn't have to be bound to time. Therefore, it would be 
permissible for the numbers to not be sequential (although they still ought 
to be monotonically increasing).

This could be relevant in the case where a DPD packet is lost. I believe 
there is no need to retransmit the R-U-THERE messages. Just begin a new 
exchange and increment the sequence number. But I don't think you can do 
this if the peer stores the sequence numbers and requires them to increase 
by 1 each time. Then you would have to follow the regular ISAKMP 
retransmission mechanism.

There is also the starting sequence number that you say MUST be generated 
randomly. That provides an additional unpredictable variable to thwart the 
attacker, which may be good practice but it's not literally a requirement. A 
bunch of the MUSTs in this section could be MAYs or SHOULDs.

Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.



_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus