[radext] Re: Review of draft-janfred-radext-radius-congestion-control-01

[Michael Richardson <[e-mail]>]

Alan DeKok <[e-mail]> wrote:
    >> This seems like a big deal, and something worth fixing, even if it
    >> takes a long time to deploy.

    >   There as similar issues with EAP-PPT.

    >   When a user has complete anonymity in a roaming environment, there is
    > substantial potential for abuse.

    >   It's likely impossible to satisfy both the user desire for anonymity,
    > and the local administrations desire to prevent abuse.

Do users successfully login, or is it high-speed endless failures that we are
trying to protect against?

    >   So the question then becomes, what can we do about it?

The *notions* I have involve:
1) getting a per-authenticator unique token back when users successfully
   login.  At the RADIUS layer.
   Supplicants also get a copy of this (inside the EAP inner layer) token.
   They can include that in their subsequent EAP outer layers, which gets
   them "faster" service.
   This just creates some new level of service, allowing anything *not*
   in that level to be more aggressively policed/traffic engineered.

2) having some kind of protocol that runs BEFORE the EAP Inner, over RADIUS,
   that provides some kind of pre-authorization.

    >   I suspect that administrators will err on the side of safety.
    > i.e. If someone @example.com is abusing the local network. the safest
    > and simplest thing to do is to ban all users @example.com.

okay, but if it's [e-mail], then it's just penalizing
other higher.edu users... and since the login does not succeed, if this
causes a ban, then someone annoyed with higher.edu can get them all banned.

    >   Those users can then complain to their administrator, who will
    > (presumably) deal with the issue out of band.

But, what can that admin do?

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

**       My working hours and your working hours may be different.         **
** Please do not feel obligated to reply outside your normal working hours **