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

Re: [RPSEC] rate limiting management traffic, redux



Hello,

At 04:43 18/04/2003 -0400, Vassilis Prevelakis wrote:
>Your two message scheme exposes router B to replay attacks. I.e. what
>is to prevent me from recording the initial packet
>        nonce_A, new_seq_A, H(secret, nonce_A, new_seq_A) 
>and sending it to B every now and then? What should A do when it
>receives the reply from B? Can I capture A's reply and feed it to
>B later on?

Valid points. We can add a time stamp to prevent reply attacks. If
a packet is older than some_time_period it will be discarded.

Let me try again. The proposed exchange may look like this:

*) Router A sends:
nonce_A, time_stamp_A, new_seq_A, H(secret, nonce_A, tim_stamp_A, new_seq_A)

*) After receiving this packet router B will perform the following
   tests:

   1) calculate the hash using his secret that is shared with the
      router A and compare the result with the hash received in
      the packet. If they do not match the packet will be rejected.

   2) Check the time_stamp_A against its own current time. If it is
      older than some predefined (or negotiated) time interval the
      packet will be dropped.

   If packet passes these checks it will be accepted as a legitimate
   request from the router A to negotiate a new sequence number and
   new secret

*) After successful verification the router B will send back:

nonce_A, nonce_B, new_seq_B, time_stamp_B, 
H(secret, nonce_A, nonce_B, new_seq_B, time_stamp_B)

   At the same time router B will set the new shared key to be
   H(secret, nonce_A, nonce_B). However, it will still accept packets
   where only the "old secret" was used.

*) After receiving this packet the router A will perform the following
   checks:

   1) calculate the hash using his secret that is shared with the
      router B and compare the result with the hash received in
      the packet. If they do not match the packet will be rejected.

   2) Check the time_stamp_A against its own current time. If it is
      older than some predefined (or negotiated) time interval the
      packet will be dropped.

*) After successful verification the router A will set its new shared
   key to be H(secret, nonce_A, nonce_B)

Please note that here we can safely drop nonces and use time stamps
instead. That can speed calculation of the hash and would not compromise
the scheme.

>If the process of verifying the incoming message and computing the
>reply (new seq num, etc) is expensive, then you also expose B to DOS
>attacks.

True again. Unfortunately, there is no easy way out of this. You will
either perform a superficial check and then accept a packet as genuine
or you will spend a bit more time verifying legitimacy of the packet
before accepting it. If we can have a check that will provide a
satisfactory level of assurance that the packet is legitimate and that
will take only 10%-15% (preferably even less) of the total processing
time of the packet, then I would classify this as a success IMHO.

Gaus
==============
Damir Rajnovic <psirt@cisco.com>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==============
There are no insolvable problems. 
The question is can you accept the solution? 

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec