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

From: "Rick Wilder" <[email-masked]>
Date: Tue, 20 May 2003 00:47:27 -0400

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-masked]> 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-masked]) 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 :)

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 20 May 2003 08:33:13 +0300

Rick Wilder writes:

 > > Note that 
 > > Section 2 attempts to update RFC 2486, which is not good. 

this was already fixed in 04 that i announced to the list a few weeks
ago.   the terms conflicting 2486 are gone.

 > > security association between the RADIUS client and server.

my draft doesn't use radius for service discovery.  the service type in
the radius request that the pe makes is VPN-Login.  so the pe already
knows what service to ask for.

what comes to the security issue, it is not at all unreasonable to
assume that there exists a security relationship between pes of a
provider and the radius servers of the same provider.  it is in the same
category than assuming that there is a security association between pes
and their snmp management system.

 > > stateful (which most current implementations are not).  So this rates 

it is very common that radius requests have side effects.  any
reasonable radius server on the market supports configuration of pre and
post authentication hooks.  otherwise routine things like checking of
simultaneous use would not be possible.

 > > This is level 2 protocol abuse.

i don't see the use of Interim Accounting for failure detection a big
protocol abuse.  that request is normally used to keep accounting
information as accurate as possible in case the nas fails and is not
able to send stop accounting request.  its use here is close to that
purpose.

 > > contains no bad ideas and therefore rates a 4 :)

thanks for the "joke".  now that you have proved your superiority, could
you please send another email that would include some "concerns"
regarding the draft, because the one i now replied to was empty of them.

-- juha

---

From: Eric Rosen <[email-masked]>
Date: Tue, 20 May 2003 10:20:53 -0400

I'm no radius expert, but I think  what Bernard Aboba is objecting to is the
proposed procedure by  which PEs seem to register  and unregister themselves
dynamically in RADIUS  as supporters of a particular  VPN instance.  This is
what he means by "service discovery", I think. 

Juha> my draft doesn't  use radius for service discovery.   the service type
Juha> in  the radius  request that  the pe  makes is  VPN-Login.  so  the pe
Juha> already knows what service to ask for. 

"Service discovery"  doesn't mean figuring out  what service to  ask for, it
means finding, from  a dynamically changing list of  servers, the servers to
connect to at some given time. 

I think that using RADIUS to get  a preconfigured list of PEs attaching to a
given  VPN is  probably  unproblematic, but  trying  to use  it to  maintain
dynamically learned PE/VPN associations  is probably overextending it, as it
is something that RADIUS is not typically used for. 

Richard> The  RADIUS  discovery draft  is  the  only  one that  includes  CE
Richard> authentication

I'm not sure that having the  CE authenticated by the SP is that interesting
in this  context, as such  authentication could be  done by the PE.   If the
authentication  could  be proxied  to  a  radius  server controlled  by  the
customer,  that might  be more  interesting,  as it  would be  immune to  SP
misconfigurations. 

Richard> and  meets all  the  discovery requirements  identified within  the
Richard> PPVPN WG so far including "Limits VPN information to only those PEs
Richard> involved  in  that  VPN",  "Extendible to  provide  information  in
Richard> additional to VPN endpoint IP address" and "Supports inter-provider
Richard> VPNs". 

The BGP-based discovery procedure meets these requirements.

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 20 May 2003 17:24:53 +0300

> is something that RADIUS is not typically used for. 

radius is very typically used to check dynamically changing information,
e.g., allowed simultaneous user limits.

-- juha