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

Richard and Juha,
 
Please note this input is not from me, but from outside the WG. Generally it's a better thing to get these issues at this stage of the process and answer them now rather than later on.
 
We should be able to get together a summary response to Bernard and advance the dialogue.
 
Juha, would you be willing to incorporate points from other posters into your response to create that summary?
 
Rick
 
 

	-----Original Message----- 
	From: [email protected] [mailto:[email protected]] 
	Sent: Tue 5/20/2003 2:04 AM 
	To: [email protected]; Rick Wilder 
	Cc: [email protected] 
	Subject: 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