call for discussion on draft-heinanen-radius-pe-discovery-03.txt

Below is feedback which raises some concerns about
draft-heinanen-radius-pe-discovery-03.txt.

I invite your participation in a two-week email discussion of this
feedback, after which a decision will be taken on whether the draft
should become a working group document.

Rick



Bernard Aboba <[email protected]> writes:

> Overall, I believe that there are things that this draft does that are

> genuinely useful and that are within the scope of legitimate AAA 
> activity. Fundamentally, I think that this draft is about 
> authenticating and providing configuration of (PP)VPN connections -- 
> which fits reasonably well with previous work in authentication and 
> configuration of VPNs -- RFC 2867 and 2868.

> That said, there is also a lot of material in this draft which is 
> inappropriate and in some cases dangerous, and so if it is allowed to 
> proceed it must be with the understanding that it will have to change 
> significantly in order to become acceptable.

> Since the same thing could be said of many other AAA-related Internet 
> Drafts, it is worthwhile to try to provide some perspective. Below 
> find a proposal for a Protocol Abuse Rating ScalE (PARSE):

> 1 = An idea so bad that it will not work at all, and anyone who tries
it
>     will likely to 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 ideas in this
>     category are so toxic that the host dies quickly.  An example of
>     this would be attempting to use AAA as an inter-domain routing
>     protocol.
> 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.  An example of
>     this would be attempting to use an unreliable AAA accounting
>     protocol for usage-based billing.
> 3 = Garden variety 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 with lots of potential security
>     vulnerabilties. Things in this category can be fixed, but
>     implementers will undoubtedly take the easy way out. The original
>     RADIUS RFCs [RFC2865]-[RFC2869] fall into this category. 5 = An 
> appropriate use of where there is some evidence of
>     real thought about security. In AAA, I unfortunately
>     cannot think of an example that fits in this category :)

> In terms of this draft, portions appear to be a 2 (Discovery) and some

> parts would be a 4 (authentication and configuration). Note that 
> Section 2 attempts to update RFC 2486, which is not good. There is 
> currently an effort to do an RFC 2486bis (talk to 
> [email protected]) so I'd recommend piggybacking on that instead. 
> Use of RADIUS for service discovery is a bad idea for many reasons, 
> not the least of which is that RADIUS security presumes a pre-existing

> security association between the RADIUS client and server.

> Use of RADIUS for authentication and configuration of (PP)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 as well so there is some precedent.

> 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).  So this rates 
> a 2.

> In Section 5.4 Interim Accounting is misused for failure detection. 
> This is level 2 protocol abuse.

> Section 7 is a largely empty security considerations section so it 
> contains no bad ideas and therefore rates a 4 :)