RE: Charter questions

["Weiss, Walter" <wweiss@Ellacoya.com>]

Bernard,

Thanks for the reply. Comments inline.

regards,

-Walter
> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: Tuesday, January 22, 2002 3:53 PM
> To: Weiss, Walter
> Cc: 'Harrington, David'; 'Wijnen, Bert (Bert)'; Durham, David;
> 'rap@ops.ietf.org'; 'Randy Bush'; 'David Mitton'
> Subject: RE: Charter questions
> 
> 
> > In this discussion I suggested
> > the following: Since DIAMETER was not capable of supporting complex
> > relationships between users and related 
> QoS/Security/Tunneling behaviors, I
> > and others wanted to address this with another protocol. No 
> one had a
> > problem with that.
> 
> Diameter now does have some functionality for provisioning of 
> tunnels and QoS behavior on a per-user basis. Has anyone in RAP
> reviewed the QoS AVP functionality?

I was not aware of the QoS or tunneling AVPs. Nor do I believe that RAP is
the right group for addressing QoS AVP issues. However, having looked at
them quickly, I would have a set of issues that would prevent me from
feasibly implementing the proposal. Many stem from the my interpretation
that the entire QoS policy is captured in a single 'value'. If anything it
reinforces my previous concerns about the approach AAA is taking to
addressing these issues: No problem, here's a new AVP.
> 
> > Given this, it would be hard to argue that the AAA folks are unaware
> > of our activities.
> 
> We certainly did talk with you about the issues you describe, 
> and you have
> fairly characterized the discussion. Note however, that those 
> discussions
> did not cross over into discussions of alternatives for network access
> authentication. 
> 
I tend to remember themes rather than words, so you may be correct. On the
other hand, I thought that we specifically discussed the need to tie "users"
to complex policies within a single protocol. It certainly makes sense to
consolidate authentication and provisioning in order to minimize setup
latencies (something that multiple protocols operating in parallel would
have difficulty accomplishing).

> > Also, let's be clear on what the requirements for the 
> Access Bind PIB were:
> > 1. Leverage existing QoS definition semantics to construct 
> user specific QoS
> > policies.
> 
> Diameter currently has an AVP that does this. 

My reading is that DIAMETER has 'a' QoS semantic. Frankly, my experience
would suggest that DIAMETER has trouble leveraging any prior work other than
RADIUS.
> 
> > 2. Because of the dynamic nature of both users 
> (particularly in a mobile
> > environment) and services, minimize the cost of setting up 
> policies for a
> > new (authenticated) user. In this particular case, both the 
> authentication
> > and the policy configuration can be set up in two messages 
> (depending on the
> > authentication protocol).
> 
> Are we talking about handling network access authentication and
> authorization, including EAP as part of this? 

NOPE. EAP requires an extra pair of messages for challenge negotiation.
> 
> > 3. Feedback/statistics on a per policy basis, rather than 
> per session.
> 
> Diameter does not do this. 
> 
> >handling all the policies... for the network edge. 
> 
> Presumably this also includes authentication and 
> authorization for network
> access?
> 
Network Access is implicit. In fact, there are models that are discussed in
the draft that allow limited Network Access policies (specifically to HTTP
based authentication servers) prior to full Network Access and user specific
policy assignments.