add Authenticator to requestKey

[davidwtf]

RADIUS protocol only uses one byte Identifier to check repeat packets. But when processing mass concurrency requests, the identifier from the same remote address also maybe duplicate. The duplicated identifier indicates the packets are same and will be dropped. But actually, in this situation, they are different packets and should not be dropped.
So I added Authenticator into the requestKey to avoid this problem. Authenticator has enough length of 16 bytes. According to the protocol, Authenticator should be random, or generated from the packet contents with secret. Some different packets hardly have the same Authenticator.

[ghost]

Thanks for the contribution. I just have a few questions:

1. Have you encountered the library dropping packets in this way, or is this a preemptive measure?
2. Do you know of any documentation that recommends this behaviour?
3. Are there other RADIUS libraries that consider the authenticator in their duplicate packet checks?

[davidwtf]

@bontibon，answer your questions:

1. Yes. It really happened. In our project, we deployed a RADIUS server for H3C's VLNS Router. The VLNS Router will accept L2TP connections and send authentication and accounting to the RADIUS server. There are thousands of connections online. And the VLNS will send thousands of accounting requests together every minute. Or when meeting some network problem，the L2TP tunnel may be dropped and rebuild very quickly. On the situation, there will be thousands of authentication packets sending to the RADIUS server concurrently.
   As the beginning, we used freeRADIUS as our RADIUS server. We wrote a python plugin for freeRADIUS to process the packets. But we found lots of information about dropping duplicated packets in freeRADIUS's logs.
   Recently, we use layeh/radius instead of freeRADIUS. But during the pressure tests, we also found the duplicated packets problem. so we hacked it a little, added Authenticator into the requestKey to avoid it.
2. No. I've read the RFC's documents and Router's directions, none of them mentioned the RADIUS's high concurrency problem. But the router's manual suggests we should choose a lower frequency of sending accounting packets when there are a lot of connections. But the lower frequency will not help, because we found the routers always sent the accounting requests together, not dispersedly.
3. I don't known. Until now, I just used freeRADIUS and `layeh/radius'. But I think adding authenticator is not a bad idea.