Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient?

From: Tom Hiller <[email-masked]>
Date: Sun, 18 May 2003 18:13:05 -0500

Hi,

I am working to understand if there are any problems for 3GPP2 with the redirect
proposal.  3GPP2 is initially focussed on MIPv4 and NASREQ applications.

From the base protocol we have:

> 
>                                  +------+
>                                  |      |
>                                  | DRD  |
>                                  |      |
>                                  +------+
>                                   ^    |
>                       2. Request  |    | 3. Redirection
>                                   |    |    Notification
>                                   |    v
>       +------+    --------->     +------+     --------->    +------+
>       |      |    1. Request     |      |     4. Request    |      |
>       | NAS  |                   | DRL  |                   | HMS  |
>       |      |    6. Answer      |      |     5. Answer     |      |
>       +------+    <---------     +------+     <---------    +------+
>      example.net                example.net               example.com
>                  Figure 3: Redirecting a Diameter Message

3GPP2 has a need for the VAAA to possibly override some of the attributes based
on local policy, so our VAAA needs to be a proxy and redirect agent.  Since
"proxy" and "redirect" are logical functions, they can be combined in one agent? 

thanks,
Tom

Bernard Aboba wrote:
> 
> > I may be out of line here, but I believe that discouraging the use
> > of proxies for Diameter EAP would greatly limit the flexibility in
> > which Diameter might be deployed.
> 
> Can you demonstrate a real-life situation in which this would be true?
> 
> > Admitedly I am thinking with my RADIUS hat on here
> 
> Diameter isn't RADIUS. One of the reasons that Diameter development was
> approved to begin with was to be able to handle these scenarios more
> securely than RADIUS.  If it turns out that Diameter in fact offers no
> advantages beyond RADIUS in terms of security, then in the immortal words
> of Ronald Reagan -- "we've been flimflammed".
> 
> > but in trying to generalize to Diameter and in a wireless scenario here
> > in Michigan, I wouldn't want to restrict or discourage the use of
> > proxies in Diameter EAP.  My $0.02 worth.
> 
> Are you deploying Diameter in a wireless network now in Michigan? If so,
> can you share with us the deployment scenario that requires a Diameter
> proxy?  Please don't respond with hypotheticals here -- I'm looking for
> real deployment plans.
> 
> To everyone else who is planning deployments of Diameter EAP -- can you
> live with only Diameter redirects?  If not, are you willing to move deploy
> Diameter CMS?

---

From: Jari Arkko <[email-masked]>
Date: Mon, 19 May 2003 14:56:55 +0300

> "proxy" and "redirect" are logical functions, they can be combined in one agent? 

I'm sure they can be, but the question is whether they can both be done
for the same session.

Can we do a redirect-based e2e Diameter EAP exchange, followed
by a proxy-based Diameter final authz round where the whole
sequence gets to agree on the attributes, followed by proxy-based
Diameter accounting? This would appear to be possible as long as
the EAP exchange and the final authz message exchange are on
two different Diameter app numbers. But details would have to
be developed.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 19 May 2003 06:22:23 -0700 (PDT)

> two different Diameter app numbers. But details would have to

Interesting. I'm assuming that the Diameter EAP exchange provides no
authorizations other than keys, then?  The "autheticate only" exchange
including keys is handled via redirects, and is then followed by an
"authorize" only" exchange that goes through a proxy.

---

From: Tom Hiller <[email-masked]>
Date: Wed, 21 May 2003 14:27:03 -0500

Jari,

You wrote the following:

> This would appear to be possible as long as the EAP exchange and the 
> final authz message exchange are on two different Diameter app numbers.
> But details would have to be developed.

I am interested in the Diameter MIPv4 and NASREQ applications. 

>                       2. Request  |    | 3. Redirection

In the above, DRL would be the AAAF, a proxy, and HMS is the AAAH.  To verify,
for MIPv4:

1) All messages above have the MIPv4 application id.

2) For MIPv4 or NASREQ to support of key distribution, it is only necessary 
to add to the MIPv4 application text that the AAAF must have a session protected 
by TLS with the AAAH, and that it may use redirect to establish a session if it
doesn't already have one. 

There are no further details to develop for NASREQ and MIPv4 applications.  Or
are there?

thanks,
Tom