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

[Thomas Narten <narten@us.ibm.com>]

Hi Bernard.

Your note outlining the Protocol Abuse & Danger Rating System (a cute
name/acronym would be really nice) is truly a classic. And also quite
useful, I think. I wonder if this rates in the class of things that
are useful to writeup more formally to make it more accessible to the
community...

Any chance you can wordsmith your note a bit so I can forward in to
the ppvpn list (it does make a comment about the author's clue level
that probably needs removing...). I don't think much editing is
needed. The text speaks for itself.

The ppvpn WG is wanting to take the document on as a WG document.

1) I want to say no, at least for now, as there are issues with this
   document. *If* this is to become a work item, we need to better
   understand what will be allowed, how it will get appropriate radius
   review, how to minimize abouse, etc.

2) It is alleged that there are some in the WG who will recognize that
   this approach has problems. Posting something like this will prompt
   them to chime in and or lead to a discussion about alternate
   approaches.

3) WG needs to have a real discussion about what the options are for
   doing discovery, and talk about approaches from the 10,000 foot
   level. Taking this document on as a WG at this time probably
   doesn't help here.

Thomas

Bernard Aboba <aboba@internaut.com> writes:

> 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
> >