Re: [RPSEC] rate limiting management traffic, redux

[Iljitsch van Beijnum <iljitsch@muada.com>]

On donderdag, apr 17, 2003, at 22:40 Europe/Amsterdam, Stephen Kent 
wrote:

> My new suggestion in this area requires a shared secret (key) between 
> the router and the entity sending the management traffic, either 
> another router or a management workstation. The key is one of two 
> inputs to a one-way function; the other input will be a sequence 
> number which will be carried with the packet.
This is similar to something I proposed about a month ago:

"Ok, how about this: we use a stream cipher to come up with a 
random-looking
data stream on both ends and use the IPsec anti-replay counter as a
pointer to the part of the data stream that is used as a magic cookie in
the current packet. We can then program the line card with enough data
to be able to check a certain number of packets per session"

> A managed device such as a router maintains a separate key for each 
> entity that is authorized to send management traffic to the device. 
> For each authorized sender, the managed device maintains the following 
> information:
> 	- the address of the sender
> 	- the shared secret
This means the crypto is done on the cards. Doing this beforehand 
elsewhere and then simply upload the results to the linecard is 
probably a better idea. A linecard with crypto hardware could of course 
do this on the fly but if we have such a linecard why not simply do 
IPsec AH?

> 	- a receive window consisting of the sequence number for the most 
> recent, valid management packet from the sender, a sequence number 
> indicating the edge for "too old" packets, plus a bit map marking 
> received , valid packets within the window.
I'm not sure requiring this bitmap is a good idea, as id adds 
complexity (that may need to be burnt into silicon).

> There are a few open issues:
> 	- where to carry the sequence number and tag
If we're doing IPsec, we already have the anti-replay counter that I 
think can easily do double duty here. For the tag we either have to 
create a completely new option or extend IPsec. Alternatively, the tag 
can be used as (part of) the IV for ESP processing.

> 	- how big is the sequence number and how big is the tag
The sequence number wraps all the time so 16 bits should be adequate or 
maybe 32 bits. As a typical window would be something like 64 packets, 
with a 32 bit tag an attacker has a one in 500 million chance of 
guessing a valid tag. A 10 Gbit link can carry several million packets 
per second so the attack would hit paydirt in a matter of minutes with 
32 bits. So I'd say at least 48 bits.

> 	- how big is the key
> 	- what one-way function to use
This is something the crypto experts should answer. I suspect that 
doing a one-way function over some static data and a sequence number 
doesn't provide enough entropy from one packet to the next to be 
secure, even for this purpose. My non-expert guess is that a stream 
cipher with the sequence number as a pointer to the stream would be 
better.

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