Subject: Re: [AAA-WG]: [Fwd: I-D ACTION:draft-belinchon-aaa-diameter-mm-app-01.txt]

From: Kuntal Chowdhury <[email-masked]>
Date: Mon, 14 Jul 2003 18:13:52 -0500

Miguel and all,

Here are my review comments for this draft. Sorry for the delay in posting them.

-Kuntal

-----------------------------------------------------------------------
Section 2.

    We assume that the SIP server and the Diameter client are located in
    the same node, so that the SIP server is able to receive and process
    SIP requests and responses which in turn relies on the AAA
    infrastructure for authenticating the SIP request and authorizing the
    usage of particular SIP services.

Comment: I think the better way to say will be -

It is assumed that the SIP server supports a Diameter interface...

Section 3.1:

    SIP server 1 will forward the SIP REGISTER request (step 4) to an
    appropriate SIP server (SIP server 2). The Diameter client in SIP
    server 2 will then request user authentication from the Diameter
    server by sending a Diameter Multimedia-Auth-Request (MAR) message
    (step 5).

Comment: The apparent assumption in this document that the SIP server 2 will
talk to the same AAA server. What if it is not talking to the same AAA server?
What identifies the AAA server to SIP server 2 that has related information
from SIP server 1?

Section 3.1:

This request will also serve to make the Diameter server
    aware of the SIP or SIPS URI of the SIP server 2, so as to return
    subsequent requests of the same user to the same SIP server 2.

Comment: the text above is not clear. the SIP server 2 can be identified
by which entity (AAA or the SIP server 1?)?

Suggestion:
This request will also serve to make the Diameter server aware of the SIP or
SIPS URI of the SIP server 2. The AAA server shall store this information so
that it can return the same to the SIP server 1 during subsequent 
re-registration by the same user.

Section 3.1:

    When the SIP server 1 receives a next SIP REGISTER request containing
    the user credentials (step 9), as there SIP server 1 does not need to
    keep a state (even there is not guarantee the SIP request to arrive
    to the same SIP server 1), the Diameter client in SIP server 1 will
    contact again the Diameter server by sending a Diameter UAR message
    (step 10) to determine the SIP server allocated to the user. The
    Diameter server will send the SIP or SIPS URI of SIP server 2 in a
    Diameter UAA message (step 11).

Comment: the paragraph needs some editorial scrub as suggested below. Also I 
think we need to mention how the same AAA server is selected (when multiple AAA 
servers are in the network).

Suggestion:

When the SIP server 1 receives a next SIP REGISTER request containing the
user's credentials (step 9), as the SIP server 1 is stateless (even there is
no guarantee that the SIP request arrives at the same SIP server 1), the
Diameter client in SIP server 1 will contact the Diameter server again by
sending a Diameter UAR message (step 10) to determine the SIP server 2
allocated to the user. The Diameter server will send the SIP or SIPS URI of
SIP server 2 in a Diameter UAA message (step 11).

Section 3.2 SIP server authenticates the user:

This should not be included in the draft. Local authentication/authorization
is certainly out of scope in AAA WG, IMHO. The draft also uses AAA server to 
perform SIP server assignment, store non-AAA specific info such as location of 
the SIP servers etc. These facts needs to discussed in the AAA WG.

Section 3.2:

    Figure 3 shows an example where a SIP server is dynamically allocated
    to serve a SIP User Agent with the support of the Diameter server.
    This may be the case of certain architectures, such as the 3rd
    Generation Partnership Project (3GPP) IP Core Network Multimedia
    Subsystem (IMS).

Comment: the SIP server 2 is dynamically allocated in section 3.1 as well.

Nevertheless user authentication/authorization solely by the SIP server is 
possible w/o AAA server's involvement (in this scheme) and dynamic SIP server 
assignment is not the main topic of the discussion. Therefore I suggest deleting 
this text.

Section 3.4:

It must be
    noted that the Diameter server also attaches the user profile in the
    Diameter Server-Assignment-Request (SAR) message

Comment: I think Diameter server needs to attach the user profile in the MAA
message as well.

Section 3.5:

    Last, if the Diameter server receives a Diameter
    Server-Assignment-Request (SAR) message that contains a
    SIP-Server-Assignment-Type set to the value DE-REGISTRATION, the
    Diameter server will proceed with the deregistration of the user.

Comment: What is the criteria for the Diameter client (SIP server 2 in this
case) to use SAR instead of STR?

Section 5.2:

   Then Diameter server MUST authorize that User-Name AVP value is able
    to register the SIP or SIPS URI included in the
    SIP-Public-User-Identity AVP.

Comment: need a little editorial scrub:
Then Diameter server MUST authorize the user as identified in the User-Name
AVP value so that the user is able to register the SIP or SIPS URI included in
the SIP-Public-User-Identity AVP.

Section 5.2:

    o  In some cases, the Diameter server is aware of a previously
       assigned SIP server for the same or different public user identity
       allocated to the same user name.

Comment: it is not clear why user name AVP will map into more than one
different public user identities? More specifically why do we need to include
the user name AVP at all when public user identity is present?

Section 5.3:

    Typically the reception of a SIP REGISTER request in a SIP server
    will trigger the Diameter client in the SIP server to send the
    Diameter SAR message. However, if a SIP server is receiving other SIP
    request, such as INVITE, and the SIP server does not have the user
    profile, the Diameter client in the SIP server may send the Diameter
    SAR message to the Diameter server in order to download the user
    profile and make the Diameter server aware of the SIP server assigned
    to the user.

Comment: When the user is not registered and the SIP server receives an INVITE
for/from the user, then by directly sending a SAR the SIP server is bypassing
auth/authz. This scenario (auth/authz bypass) may not be allowed in all
networks. Moreover, receiving a REGISTER for a user that has no context in
the SIP server should generate MAR message not SAR.

Section 5.6:

                  [ Auth-Grace-Period ]
                  [ Authorization-Lifetime ]

Comment: Since SIP server 1 is stateless, therefore what is the purpose of these 
two AVPs in the LIA message?

Section 5.12:

       OPEN ISSUE: How to avoid that the same SIP server is chosen again,
       and we enter a loop.

Comment: Ideally, the Diameter server flags the SIP server to be "busy" or a
similar tag, so that while returning a UAA next time it does not include this
server for a new user.

Section 6.1.1:

    o  DIAMETER_SERVER_SELECTION                       2xx5
       The Diameter server has authorized the registration. The user has
       already a SIP server assigned, but it may be necessary to select a
       new SIP server for the user.

Comment: Not sure how often this will happen, but the appropriate value name
should be DIAMETER_SERVER_RESELECTION

Section 7.1:

       SIP-Charging-Information :: = < AVP Header: TBD >
                          [ Primary-Event-Charging-Function-Name ]
                          [ Secondary-Event-Charging-Function-Name ]
                          [ Primary-Charging-Collection-Function-Name ]
                          [ Secondary-Charging-Collection-Function-Name ]
                        * [ AVP]

Comment: There should be a sentence that says that these functions can all have 
the same value. These things may very well be part of the Diameter server (AAA
server) and charging and accounting is part of AAA.

Section 7.4:

    o  UNREGISTERED_USER (3)
       The SIP server has received a SIP request (e.g., SIP INVITE)
       addressed for a public user identity that is not registered.

Comment: Why doesn't the SIP server send a MAR in this case?

Section 7.4:

    o  AUTHENTICATION_FAILURE (9)
       The authentication of a user has failed.

Comment: Why would the SIP sever send a SAR with Auth failure code? Ideally
the Authentication needs to be done in the Diameter server.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 21 Jul 2003 17:20:26 +0300

Hi Kuntal:

Thanks a lot for your comments. Please see some answers inline.

/Miguel

> Here are my review comments for this draft. Sorry for the delay in 

Yes, another way to express the same sentence.

> talk to the same AAA server. What if it is not talking to the same AAA 

Yes, the assumption is correct: there is only a single Diameter server. Of 
course you can have a cluseter configuration supporting redundancy and all 
the fancy things you want, but from the logical perspective the assumption 
is that there is a single Diameter server per realm.

> What identifies the AAA server to SIP server 2 that has related information

I am not sure if I understand your question. The idea is that SIP server 2 
is something allocated dynamically, perhaps when the user registers or 
something like that. So it may change from time to time... The Diameter 
server keeps track of the SIP server 2 URI, as a way to provide extra 
routing information (apart from the authorization function) to SIP server 1.

> by which entity (AAA or the SIP server 1?)?

Ok, I will try to clarify. The SIP server 2 will instruct the Diameter 
server to "save" its URI, so that subsequent request like step 2 end up 
with the same routing information (SIP server 2 URI) in step 3.

> re-registration by the same user.

In general your proposed text is fine, but the word is not correct. First, 
there shouldn be any "shall", whichi is normative information, in section 
3, which is "Overview of operation". Second, you are assuming that the 
request is always a register (subsequent re-registration), which is not 
correct. It could be any other request address for the same user (e.g., see 
  section 3.3 and the LIR/LIA commands).

So if you combined the above correction to your text, you will most likely 
end up with the same text I wrote originally ;-)

> Comment: the paragraph needs some editorial scrub as suggested below. 
> Also I think we need to mention how the same AAA server is selected 
> (when multiple AAA servers are in the network).

Do we have a requirement to cover the case when there are multiple diameter 
servers in the same network? 3GPP contains a solution, over a different 
interface (so called Dx interface) to provide this functionality, but I 
think this something of no interest outside 3GPP.

> SIP server 2 in a Diameter UAA message (step 11).

OK with the suggestion.

> is certainly out of scope in AAA WG, IMHO. The draft also uses AAA 
> server to perform SIP server assignment, store non-AAA specific info 
> such as location of the SIP servers etc. These facts needs to discussed 
> in the AAA WG.

Today SIP servers can authenticate users. It is happening everyday in the 
Internet. What this draft offers is two possibilities, so that operators 
can decided which one to choose to suit their needs. These two posibilities 
are:

a) The Diameter server is authenticating the users. In this case, the SIP 
server terminates the SIP authentication, but the SIP server merely proxies 
the credentials to the Diameter server. This may be a case widely agreable 
for most of the internet needs.

b) The Diameter server delegates the authentication to the SIP server. In 
this case, the SIP server terminates the SIP authentication and downloads 
some authentication vectors from the Diameter server, as for to execute 
authentication in the SIP server. This is the solution chosen by 3GPP. It 
has a number of advantages, like providing a distributed architecutre that 
relieves the Diameter server from the burden of computing authentication. 
This mechanism is also in use today, so I don't thing that precluding its 
standardisation will help to achieve interoperability between different 
implementations.

> Comment: the SIP server 2 is dynamically allocated in section 3.1 as well.

Yes, is that a problem? They are two mutually exclusive scenarios.

> 
> Nevertheless user authentication/authorization solely by the SIP server 
> is possible w/o AAA server's involvement (in this scheme) and dynamic 
> SIP server assignment is not the main topic of the discussion. Therefore 
> I suggest deleting this text.

I don't agree. I think that deleting text is not the way to expressing 
ideas, and I don't believe we will achive much by deleting this text.

What this section is demonstrating is how to achieve authentication in a 
SIP server with support from a Diameter server. The Diameter server is 
still performing a number of functions, being authorization the most 
significant one. The SIP server does not include a database of users of the 
realm, not even credentials whatsoever. So the only mechanism to authorize 
the user is to contact the Diameter server.

> Comment: I think Diameter server needs to attach the user profile in the 

Mmmm... Yes, I think there is an inconsistency in the text, because if the 
Diameter server is authenticating the user (like it's described in section 
3.2), the Diameter server has to send the user profile in MAA. However, MAA 
does not allow the SIP-User-Data AVP to be carried in. I need to solve this 
inconsistency.

> case) to use SAR instead of STR?

RTR flows in the direction from Diameter server to Diameter client, whereas 
SAR flows from Diameter client to Diameter server. Consequently, the SIP 
server always sends SAR.

> the SIP-Public-User-Identity AVP.

Ok with it.

> the user name AVP at all when public user identity is present?

Yes, yes. Public User identity (something that will change soon to SIP-AOR 
(Address of record, as per RFC 3261), is a SIP or SIPS URI. It is some 
address that you distribute in your business cards (similar to your e-mail 
address) and other users initiate communications to you by pointing to your 
SIP AOR.

The user name is just some identity used to authenticate the user. It is 
not a SIP or SIPS URI, it is not widely known, and it is know known to 
initiate communications against you.

So both identities have to be present for different purposes.

> the SIP server should generate MAR message not SAR.

A lot of staff in the previous paragraph... First, let me try to describe a 
scenario. Imagine that you're SIP phone is off, so you are not registered 
to the network, and someone calls you. The call will end-up in a SIP server 
that knows nothing about you, other than "this is a call addressed to 
Kuntal". The SIP server cannot authenticate you, because you are offline. 
But the SIP server still needs to download the user profile, because it 
needs to know if you have services (e.g., voicemail service or similar) to 
execute.

So the SIP server contacts the Diameter server to authorize the call for 
this user, download the user profile, and informs the Diameter server that 
this SIP server is now serving the non-registered user.

Can you see an authentication bypass in this scenario? I don't. When the 
user goes online and registers, then it will be authenticated.

> Comment: Since SIP server 1 is stateless, therefore what is the purpose 
> of these two AVPs in the LIA message?

I need to double check this. I must say I am not sure why these AVPs are 
here. But the fact is that SIP server 1 MAY be stateless, we don't force it 
to be stateless (but I don't think this changes the question about the 
presence of the AVPs).

> similar tag, so that while returning a UAA next time it does not include 

No, this does not work. The thing is that UAA does not return a list of 
possible SIP servers, but it returns a list of "capabilities" that the 
selected SIP server need to fulfil for this particular user.

So a user may require a SIP server that is able to execute Java (capability 
x) and SIP CGI (capability y). The Diameter server will indicate (in UAA) 
that the user requires a SIP server with capabilities x and y. SIP server 1 
will use this information to select SIP server 2 (according t those 
capabilities).

The situation that we discribe in this paragraph will force the whole 
allocation process to start, but there is a chance that SIP server 2 is 
again chosen (by SIP server 1 or any other SIP server), so we will be in a 
look. So that is open issue that I have listed.

> should be DIAMETER_SERVER_RESELECTION

Ok.

> Comment: There should be a sentence that says that these functions can 
> all have the same value. These things may very well be part of the 
> Diameter server (AAA

Yes, that is correct. Actually, I think the there should be a couple of 
AVPs that allow repetition, and we should forget about Primary and 
Secondary. I will make these changes in the next version.

> Comment: Why doesn't the SIP server send a MAR in this case?

Because this in this case the SIP server is interested to server the 
request, and download the user profile. SAR carries a "store" operation, 
whereby the Diameter server stores the address of the SIP server serving 
the user. MAR carries an authorization operation to install a registration.

> the Authentication needs to be done in the Diameter server.

We discussed before the scenario where the Diameter server delegates the 
authentication to a SIP server. So this is the mechanism whereby the SIP 
server indicates the Diameter server that authentication failed.

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