Re: radius in draft-heinanen-radius-pe-discovery-03.txt

[Bernard Aboba <aboba@internaut.com>]

This is a difficult situation. As we've learned from 3GPP, IEEE 802 and
most recently, SIPPING, telling WGs that they can't do RADIUS work
typically results in it being done anyway, but without any IETF review.
Typically this results in the worst possible outcome -- a bad idea done
badly (as opposed to a bad idea not done at all, or a bad idea with a
veneer of thought added on: "whipped cream on a road apple").

So, let's see if we can calibrate the scale of 1 to 5 here.

1 = An idea so bad that it will not work at all, and anyone who tries it
    will likely be weeded out by Darwinian selection. Mike O'Dell has
    suggested that we not choose to fix things in this category so as
    to allow evolution to continue to work, since things in this
    category are so toxic that the host dies quickly. IEEE 802.11f
    RADIUS usage may be in this category.
2 = A bad idea that will work well enough to get significant deployment,
    but will show intermittent failures and poor interoperability and
    therefore can cause significant damage which the IETF will have to
    clean up later. For things in this category, darwinism may not be a
    satisfactory solution, since the host may not know they are sick
    until they have spread the problem to a significant population.
    In general, I think we need to be more strongly discouraging
    such things rather than hoping they will go away. SIPPING and 3GPP
    (prepaid) use of RADIUS accounting is in this category.
3 = Garden variety RADIUS abuse -- there are better ways to do this,
    but one could conceive of it working. This category is like a
    chronic condition in that in the long term these kind of
    mediocre ideas can degrade the quality of the Internet experience,
    and lead to shortened lifespan for adopters, so that education
    and discouragement is appropriate.
4 = An appropriate use of RADIUS with lots of potential security
    vulnerabilties. Things in this category can be fixed, but
    implementers will undoubtedly take the easy way out.
    draft-chiba is in this category.
5 = An appropriate use of RADIUS where there is some evidence of
    real thought about security. Since there are no known uses of
    RADIUS in this category, there's not much to say :)

In terms of this draft, portions appear to be a 2 (Discovery) and some
parts would be a 3 (authentication). Note that Section 2 redefines RFC
2486, which is not good. Use of RADIUS for service discovery is a bad idea
that seems to have legs (IEEE 802.11f adopted this model too) so ignoring
it will not make it go away. However, use of RADIUS for authentication or
configuration of VPNs is within the scope of things envisaged in RFC
2867-68. Similar things were done in draft-congdon with respect to dynamic
configuration of VLANs, which is somewhat similar.

Section 5.1 puts constraints on the implementation of the RADIUS backend
database, and appears to require that RADIUS servers be stateful (which
most current implementations are not).

In Section 5.4 Interim Accounting is misused for failure detection. This
is a level 2 problem, and should be actively discouraged.

Section 7 shows no thought about security so that section rates a 4 :)

Overall, there is a kernel of useful functionality in here that customers
will probably use. If the IETF is not involved, it will get done anyway --
and probably very badly at that. With IETF involvement it will probably be
done in a mediocre way and will take a long time because clearly the
authors lack clue but may not be easily convinced of that. But it will get
done either way.





On Thu, 24 Apr 2003, Thomas Narten wrote:

> [resend, including iesg]
>
> Hi Bernard.
>
> On a scale of 1 to 5 (1 being lowest), how appropriate a usage of
> radius is the following:
>
> draft-heinanen-radius-pe-discovery-03.txt
>
> This is apparently being considered by the ppvpn wg as a way to solve
> VPN discovery. The claim is being made that their is WG support for
> adopting this document as a WG item.
>
> >From my perspective, this isn't how I thought radius was intended to
> be used (e.g., a backend database for storing VPN information,
> including some topology aspects).
>
> Thomas
>