Subject: [AAA-WG]: RE: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 10 Jul 2003 10:38:13 -0500

> -----Original Message-----
> From: Miguel A. Garcia [mailto:[email-masked]] 
> Sent: Thursday, July 10, 2003 6:13 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]'; [email-masked]'
> Subject: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt
> 
> 
> Inline...
> 
> Jayshree Bharatia wrote:
> 
> > [JB] The current title of section 3.2 is "SIP server 
> authenticates the
> > user" so you may need to correct this to reflect your above 
> point. I am 
> > not sure how (and where) SIP server delegates 
> authentication to the SIP 
> > server in the current flow. I thought SAR basically does 
> what MAR is 
> > doing plus provides SIP server address to the Diameter 
> Server for the 
> > future use. Is it what you are referring to? It will be 
> useful if you 
> > show set of commands used when the Diameter server is 
> authenticate the 
> > user vs the SIP server authenticate the user.
> 
> I will change the title of section 3.2 to reflect the delegation.
> 
> The Diameter server delegates authentication to the user in a 
> MAA command. 
> MAA contains, in this case, one or more SIP-Auth-Data-Item  
> (authentication 
> vectors). SAR has another functionality of downloading the 
> user profile.
> 
[JB] Ok.  Currently, the description of steps 5 and 6 (MAR/MAA) in both
sections (3.1 and 3.2) have similar text. So please clarify your point
further in section 3.2 so that this functionality becomes obvious.

> [snap]
> >  >
> >  > > - This section says that the Diameter server must 
> include either 
> > the  > > address of
> >  > >   the SIP server  or the capability needed by the SIP
> >  > server. Does it
> >  > > mean that
> >  > >   requesting SIP server always have capability to derive
> >  > next hope based
> >  > > on the
> >  > >   capabilities received from the AAA? Why do we have 
> this additional
> >  > >   requirement.
> >  > >
> >  >
> > [JB] Sorry for the confusion I am referring to section 5.2 only (4th
> > paragraph) which is specific to UAA.
> > 
> > "When the authorization procedure succeeds, the Diameter server
> > constructs a User-Authorization-Answer (UAA) message that 
> MUST include 
> > either the address of the SIP server already assigned to 
> the user or the 
> > capabilities needed by the SIP server (Diameter client) to select 
> > another SIP server for the user."
> > 
> > My point is why UAA (and hence UAR) is tied with having SIP server
> > address or SIP server capabilities? My understanding from 
> reading this 
> > draft is that UAR can be triggered upon receipt of any SIP 
> request and 
> > may be used any time during the transaction. If this is the 
> case than 
> > the requirement on having the SIP server address or 
> capabilities should 
> > be soften. My suggestion is to separate Authorization 
> operation from the 
> > explicit Assignment/Retrieval of the SIP server address.
> 
> We agree that the SIP server uses UAR (and UAA) to request 
> Authorization to 
>   provide a service. The service may be "user wants to 
> register (REGISTER 
> message)" or "user wants to establish a session with another 
> guy (INVITE 
> message)". That is clear for you and me.
> 
> I think that in any case a SIP edge proxy may need to know:
> a) Whether the proxy is authorized to provide the service to the user
> b) If the proxy needs some routing information (e.g., the address of 
> another proxy that is serving the user).
> 
> We could of course separate both commands, but then we 
> require one more 
> roundtrip operation, because afterach each UAR, the Diameter 
> client will 
> require routing information, always. That's the reason why they are 
> combined. And because this command is used for routing 
> realtime traffic, I 
> wouldn't like to add one more rountrip of delays to the 
> session setup time. 
> Don't you agree with this motivation?
> 
[JB] As I have indicated in my earlier email, we may not need both the
functionality (mentioned as points a and b in your reply) at all of the
time. So it will be good if you can replace MUST to SHOULD in the following
quote of section 5.2. 
"When the authorization procedure succeeds, the Diameter server constructs a
User-Authorization-Answer (UAA) message that MUST include either the address
of the SIP server already assigned to the user or the capabilities needed by
the SIP server (Diameter client) to select another SIP server for the user."

> Regards,
> 
>        Miguel
> 
> 
> 
> -- 
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                          Jorvas, Finland
> mailto:[email-masked]     Phone:  +358 9 299 3553
> mailto:[email-masked]        Mobile: +358 40 5140002
> 
> 
> 
> 
> 
>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 10 Jul 2003 18:55:02 +0300

Jayshree Bharatia wrote:

> time. So it will be good if you can replace MUST to SHOULD in the 
> following quote of section 5.2.
> 
> constructs a User-Authorization-Answer (UAA) message that MUST include 
> either the address of the SIP server already assigned to the user or the 

Jayshree, I am trying to find out the applicability of your comment. It 
would be good to understand the scenario you are thinking of. As far as I 
understand, you are saying that there may be a third scenario where the SIP 
proxy is just interesting in the User Authorization but not in doing 
further routing. Is this correct?

If it is, I think it is a dangerous scenario, because the SIP proxy will 
not be able to determine whether the request has to be routed to another 
proxy or not. So if you have a scenario in mind, it would be nice to 
understanding.

Further more, your proposal to downgrade the "MUST" to a "SHOULD" does not 
help, because from what I understand from your comments, what you want is 
to deploy SIP servers that do no have the server allocation functionality. 
If that is the case, writing normative text to the Diameter server will not 
help.

/Miguel