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

Re: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime)



Hi Andrew,

I agree with you and
 think DoS-resistant protocols should work in the following order:
(1) The responder carries out expensive (but initiator-independent)
    computation.
(2) The initiator carries out expensive (and responder-dependent)
    computation. This computation must also be session-dependent.
(3) With light computation, the responder checks whether the responder
    has really completed (2).
(4) The responder carries out expensive (and initiator-dependent)
    computation.

(1) can be pre-computed.
If the resultant state is too large,
we can be helped by "stateless connection" (state materials are
encrypted by local secret key and sent back and forth
between the responder and the initiator. This encryption can be
a fast symmetric-key encryption and the key can be used many times.).

Please consult about details with
http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt.

Finally, I'd like to point out that
Base Mode (draft-ietf-ipsec-ike-base-mode-01.txt)
is aimed at DoS resistance but
it does not follow the protocol design direction
listed above as (1)-(4).
Signature-verification cost might probably exhaust
the responder's resource, for example.
(Even if RSA signature verification is not really expensive
due to the deployment of small exponent,
we had better design the protocol in a DoS-resistant way,
not devoted to a single specific algorithm.)

Andrew Krywaniuk <akrywaniuk@TimeStep.com> wrote:
>>>  Sankar> Why is "do nothing" a safe choice for the receiver of the bad
>>>  Sankar> IPSec packet (IPSec packet without SA)? How does sending a
>>>  Sankar> 'invalid spi' notify to the sender of the ipsec packet affect
>>>  Sankar> the safety of the receiver?  Isn't sending a notify better
>>>  Sankar> than doing nothing?
>>
>>Paul:
>>
>>> Not necessarily.  Sending a notify consumes resources that are not
>>> consumed by simply discarding the offending packet.  Since 
>>> DOS attacks 
>>> basically are attempts to get the receiver to consume lots of
>>> resources, the less resources you use in dealing with invalid packets
>>> the safer you are from DOS attacks.
>>
>>Andrew:
>>
>>Not exactly.
>>
>>You can't realistically ever fully protect against DoS attacks. But a good
>>rule of thumb is to force a DoS attacker to consume as much of his own
>>computing power as he consumes of yours. 
>>
>>You receive a spoofed packet and it causes you to perform a DH
>>exponentiation = BAD.
>>You receive a spoofed packet and it causes you to generate an unencrypted
>>notify = OK.
>>
>>Generating the unencrypted notify could involve nothing more than a hash
>>table lookup (which you had to do anyway to determine that the spi/cookie
>>was invalid), a couple of
>>memcpys, and a SendBuffer.
>>
>>Plus, sending the unencrypted notify allows the peer to generate an alarm:
>>SOMEONE IS SPOOFING PACKETS!!! (since either you generated the notify in
>>response to a bad spi/cookie or the notify itself was spoofed)
>>
>>But if you respond to the unencrypted notify by initiating a new SA then you
>>are at the mercy of a DoS attacker.
>>
>>Andrew
>>_______________________________________________
>> Beauty without truth is insubstantial.
>> Truth without beauty is unbearable.
>>

---- **** ----
 Kanta MATSUURA, Ph.D.
  Lecturer
  3rd Department,
  Institute of Industrial Science, University of Tokyo,
  Roppongi 7-22-1, Minato-ku, Tokyo 106-8558, JAPAN
    Tel: +81-3-3402-6231 (ext. 2325)
    Fax: +81-3-3479-1736
    E-Mail: kanta@iis.u-tokyo.ac.jp


References: