Re: [RPSEC] rate limiting management traffic, redux

[Vassilis Prevelakis <vp@mcs.drexel.edu>]

Damir Rajnovic <gaus@cisco.com> wrote:
> If you send nonce_A and H(secret, nonce_A) you will ensure that router A
> is authenticated because (by the definition) only A knows the secret.
> The router A can also offer a new sequence number in the same packet.
> To make guessing even harder we can say that the router A should
> send H(secret, nonce_A, new_seq_A).
> 
> By sending only nonce_A you are forcing the router B to respond to
> any request it receives. It does not have any means to discriminate
> which requests are legitimate and which are not. By sending a hash
> in the first packet you can authenticate the sender.
[...]
> B can reply with nonce_A, nonce_B, new sequence B and H(secret,
> nonce_B, new_seq_B) and H(secret, sequence A+1). The first hash
> H(secret, nonce_B, new_seq_B) server to initialize the new
> sequence number for the reverse session (from A to B). The second
> hash, H(secret, seq_A+1) is used normally as envisaged. The router
> A will check it first to determine if it will accept the packet
> or not.

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?

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.

Must we rediscover the wheel in this group? Why don't we all take a break
to read a good book on communications security and return after a week
or so.

**vp

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