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

Rick

I wonder what the results would be if the other discovery and signalling
drafts defined by PPVPN so far were evaluated using a "Protocol Abuse Rating
Scale (PARSE)"? I suspect that most of them (if not all) would also receive
2's and 3's.

The RADIUS discovery draft is the only one that includes CE authentication
and meets all the discovery requirements identified within the PPVPN WG so
far including "Limits VPN information to only those PEs involved in that
VPN", "Extendible to provide information in additional to VPN endpoint IP
address" and "Supports inter-provider VPNs".

It seems to me the main issues raised so far are: 

1) Presumption of pre-existing security (which is more relevant in the
inter-AS case)
2) Requirement that RADIUS databases be stateful
3) Use of interim accounting for failure detection

Considering Juha's replies below, can we get further clarification on what
the *actual implications* of the above issues are, and on what the 'many
reasons' are that makes RADIUS a bad idea for PE (not service) discovery?

Thanks,

Richard

-----Original Message-----
From: Juha Heinanen [mailto:[email protected]]
Sent: 20 May 2003 06:33
To: Rick Wilder
Cc: [email protected]
Subject: call for discussion on
draft-heinanen-radius-pe-discovery-03.txt


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.

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

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.

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

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.

 > > In Section 5.4 Interim Accounting is misused for failure detection. 
 > > 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.

 > > Section 7 is a largely empty security considerations section so it 
 > > 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