[RP-PPPoE] pppoe-server efficiency (was Re: IPv6 support)
David F. Skoll
dfs at roaringpenguin.com
Tue Jul 30 15:18:10 EDT 2013
On Tue, 30 Jul 2013 12:07:20 -0700
Insane Laughing Clown <mike-rppppoe at tiedyenetworks.com> wrote:
> There's some general design issues. For example, a bad client or herd
> of them all shitting out padi can overrun the server since there's no
> sanity checking on the number of outstanding requests in flight.
A PADI does not allocate any server-side resources. The design of
PPPoE is such that there is no way for a PPPoE server to prevent this
attack; senders can fake their MAC addresses and blast PADIs as fast
as they like. The only countermeasure is not to allocate resources
in response to a PADI.
By the time you get a PADR, you can be reasonably sure you are speaking
to a real client because it had to have received a cookie. PADR-time
is when you can limit outstanding requests.
> PADT processing pays the lookup performance penalty every time one
> is received wether it's valid or not.
No, that's not true. Check the source code:
/* Get session's index */
i = ntohs(packet->session) - 1 - SessOffset;
if (i >= NumSessionSlots) return;
if (Sessions[i].sess != packet->session) {
syslog(LOG_ERR, "Session index %u doesn't match session number %u",
(unsigned int) i, (unsigned int) ntohs(packet->session));
return;
}
/* If source MAC does not match, do not kill session */
if (memcmp(packet->ethHdr.h_source, Sessions[i].eth, ETH_ALEN)) {
syslog(LOG_WARNING, "PADT for session %u received from "... boring stuff removed ...);
return;
}
Those are constant-time operations.
> PADR isn't limited in any way and
> bad clients can flood the server causing unlimited numbers of pppd's
> to be created until the tables are full.
That's where the -x option would come in handy and I agree... it needs
to be made more efficient. All that's needed is to make
count_sessions_from_mac more efficient and to use a doubly-linked list
for quick deletion of busy sessions.
> Personally, there should be both numerical limits on the number of
> sessions as well as the rate as which any given client is allowed to
> create or terminate sessions and the only way to do that would be
> with a hash table.
Yes, you could do that if you were ambitious. :) From the man page:
Note that pppoe-server is meant mainly for testing PPPoE clients. It
is not a high-performance server meant for production use.
:) That's my get-out-of-jail-free card. :)
Regards,
David.
More information about the RP-PPPoE
mailing list