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

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 07 Aug 2003 10:58:13 +0300

Hi Avi:

First let me apologize for the delay in answering your mail. I was 
having a few days of vacation, something common in summer time in Europe.

Now, thanks a lot for your comments. Certainly they are valuable. 
Please see my answers below.

I have seen your e-mail with your second round of comments, that I 
will try to answer asap.

/Miguel

Avi Lior wrote:

> This is my first installment of comments up to section 5.  Stay tuned for
> the next section
> 
> [AL] General Comments:
> 
> I did not read other peoples reviews. This way if there is duplication
> you will get an amplication effect which could be useful. After my
> review i will read the other ones.
> 
> However, I did read the first couple of reviews that talked about the name
> change
> and perhaps it would be a good idea to change the name to reflect the
> "SIPness" of this draft.
> 
> Also I am not a SIP expert so you are getting the view of a non-sip
> expert reviewer which is a good thing. But make sure you get a SIP type
> person to review.
> 
> [AL] End of general comments
> 
> 
> 2. Introduction
> 
>    This document specifies the Diameter Multimedia Application. This is
>    a Diameter application that allows a Diameter client to request
>    authentication and authorization information to a Diameter server for
>    Session Initiation Protocol (SIP) [6] based IP multimedia services.
>    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.
>    
> [AL] What is a node? The SIP server is acting as a Diameter Client.
> Perhaps a better way to say this is: In this document we assume that
> the SIP server is acting as a Diameter Client.....

Good question: what is a node? I guess what we try to say is that the
SIP server function and the Diameter client function are co-located,
or linked by some sort of communication (e.g., inter process
communication or some non-standardized mechanism) that links both
processes. The general perception is that both functions (SIP and
Diameter) are physically located in the same processor, although it
might not be the case. I don't know how to summarize all this, but we
will try.

Ok with your second comment.

>    
> 
>    This document provides Diameter procedures to implement certain
>    required functionality when SIP is the protocol chosen to initiate
>    and tear-down multimedia sessions. However, this document does not
>    mandate any particular mapping of SIP procedures to Diameter
>    Multimedia procedures, nor this document 
>    
> [AL] mandate

OK

>    
>    any particular sequence of
>    events between SIP and Diameter. In some cases, though, this document
>    provides with useful examples to show the interaction between SIP and
>    Diameter Multimedia in order to achieve the desired functionality.
> 
> [AL] Delete " In some cases, though," and  "with"

ok

> 
>    The Overview chapter (Section 3) provides the reader with
>    non-normative description of the Diameter multimedia commands and
>    responses and some guidance of its linkage with SIP procedures.
> 
> [AL] Can't you use Informative for non-normative?

Yes, no problem... I was wondering of the difference between both terms...

> 
> .....
> 
> 3. Overview of operation
> 
>    This section provides an informative description of how the Diameter
>    Multimedia application can be used together with SIP. By no means
>    this section mandates any specific usage of the Diameter Multimedia
>    application nor  it mandates a specific mapping between SIP and
>    Diameter messages. This section is just a collection of examples that
>    shows how the required AAA functionality can be achieved in
>    conjunction with SIP.
> 
> [AL] Change: "application nor it mandates a " to: "application nor does
> it mandates a " above.

ok

>  
> 
> 
>    According to Figure 2 a SIP User Agent Client (UAC) sends a SIP
>    REGISTER request (step 1) to its home domain. SIP server 1 will
>    receive the SIP request. We assume that this SIP server may be
>    located, e.g., at the edge of the administrative home domain. The
>    Diameter client in SIP server 1 will contact its Diameter server by
>    sending a Diameter User-Authorization-Request (UAR) message (step 2)
>    to determine if this user is allowed to receive service, and if so,
>    request the address of a local SIP server capable of handling this
>    user.
>   
> [AL] What do you mean by SIP server 1 will contact *its* Diameter
> server. Couldn't it contact a Diameter server? There could be more then
> one Diameter server no?

What I meant is that SIP server 1 will contact a Diameter server in
its own realm. I will clarify this sentence.

However if have a short discussion in the past on whether there is a
requirement for a network to implement several Diameter servers.
Coming from a 3GPP view, the draft has been assuming that, for a
paricular user, all its data is stored in a single Diameter server.
One can have servers configured in redundant fashion, clusters, or
similar things (in order to provide redundancy mainly). But all those
servers will contain the same data (will be mirrors), so from the
functional perspective, there will be only one Diameter server in the
network.

Now, I would like to understand if this assumption is correct,
otherwise we will need to provide the appropriate mechanisms in the
draft to make it work in other environments.

>    
>    The Diameter server will answer with a Diameter
>    User-Authorization-Answer (UAA) message (step 3), which will indicate
>    either a list of capabilities that the SIP server 1 may use to select
>    an appropriate SIP server (SIP server 2) or a SIP or SIPS URI
>    pointing to SIP server 2.
> 
>    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). 
>    
> [AL] Must it be the same Diameter server? Couldnt it be a different one?

In this case I believe it should be the same (or a cluster of Diameter
servers sharing the same data; I will refer to this as one Diameter
server). The issue is than in step 5 the second SIP server will inform
the Diameter server that such second SIP server is serving the user.
Consequently, further Diameter requrests (such as UAR in step 10) or
the LIR command (step 2 in Figure 2) will return in the response
routing information, that is, the address of SIP server 2.

This point is of vital importance for the whole system. If there are
several Diameter servers (with a discongruent view of the data, such
us serving SIP server or user profile), we will not achieve the
desired functionality.

>    
>    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.
>  
> [AL] So what you are saying here is that you inform the Diameter server
> of the SIP Server selected by SIP1.

Correct. In doing so, the second SIP server "registers" itself in the
Diameter server.

>   
> [AL] What subsequent requests? Why wouldnt subsequent commands go
> directly to SIP2?

I will explain this with the help of figure 4. Figure 4 is an example
of a user calling sip:[email-masked]. The SIP INVITE
will arrive to any of the multiple SIP server 1. This is done by using
the procedures in RFC 3263 (Locating SIP servers). This RFC makes
usage of DNS to find "entry points" or "edge" SIP servers.

So the INVITE in step 1 of Figure 4 will arrive to an edge SIP server
in ericsson.com. This SIP server does not know the address of the SIP
server that is triggering or providing services to me, so SIP server 1
sends the LIR command to a Diameter server in the ericsson.com real
(step 2 in figure 4). LIA will return the address of the SIP server
allocated to me, that may be something like sip:server33.ericsson.com
(in the example this will correspond to SIP server 2).

What I wanted to say is that my SIP URI will be in the format of
user@domain rather than [email-masked], so in general other SIP
requests will ***not*** be addressed to
sip:[email-masked] but to 
sip:[email-masked] instead. So those subsequent
requests need the routing information from the Diameter server, in 
order for the SIP request to reach the appropriate SIP server.

> 
> [AL] Also if you have multiple Diameter servers one used by SIP1 the
> other used by SIP2 will this work? It would only work if the state
> (which SIP server) can be shared by both Diameter servers. Alternatively
> it would work if Diameter serving SIP1 returns SIP2 again.

Yes, this was part of the discussion above. I think the assumption is 
that there is a single point of data storage, so that even if there 
are multiple servers, they are just mirrors, as they are sourcing the 
same data.

>    
>    The Diameter server will respond with a Diameter Multimedia-Auth-Answer
>    (MAA) message (step 6) with Result-Code AVP set to the value
>    DIAMETER_MULTI_ROUND_AUTH. The Diameter server will also include a
>    challenge, which the SIP server 2 will use to map into the
>    WWW-authentication header in the SIP 401 (Unauthorized) response
>    (step 7), which is sent back to the SIP server 1 and then to the SIP
>    UAC (step 8).
>    
> [AL] Seems to me that if SIP1 kept state there would be fewer messages.
> 
>    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).
> 
> [AL] The above par. in paritucal the first sentence needs to be cleaned
> up. The first sentence is almost the entire paragraph ;-)

OK

>  
>    SIP server 1 will then forward the SIP REGISTER request to SIP server
>    2 (step 12). SIP server 2 will extract the credentials from the SIP
>    REGISTER request. The Diameter client in SIP server 2 will send those
>    credentials in a Diameter MAR message (step 13)to the Diameter
>    server. This message will also enable the Diameter server to identify
> 
> 
> 
> Garcia-Martin, et al.    Expires December 15, 2003              [Page 7]
> 
> Internet-Draft      Diameter Multimedia application            June 2003
> 
> 
>    the URI of SIP server 2, so as to return subsequent requests to the
>    same SIP server 2. At this point, the Diameter server will be able to
>    authenticate the user, and upon success, will return a Diameter MAA
>    message (step 14) with the AVP Result-Code set to the value
>    DIAMETER_SUCCESS. The Diameter MAA message will also include the user
>    profile information, which the SIP server 2 will use to give service
>    to the user.
>    
> [AL] I thought Diameter already remembered the URI of SIP server 2 in
> the exchange that took place in Step 5?

Yes, your statement is correct. Althoug the MAR command will contain 
the SIP-Server AVP, it does not serve the purpose of storing the SIP 
server 2 URI in the Diameter server.

> 
>    SIP server 2 will then generate a SIP 200 (OK) response (step 15)
>    which is forwarded to SIP server 1 and eventually to the SIP UAC
>    (step 16).
>    
>  [AL] How does Diameter Server know that the second UAR in (step 10) is
>  associated with the same session as the one in MAR/MAA in (step 6)?
>  What happens if the UAC is involved in multiple simultaneous operations
>  some of which would be routed to different SIP servers?
>  

Both UAR and MAR commands include a mandatory SIP-Public-User-Identity 
(soon to be renamed as SIP-AOR, Address of Record). This is the 
identity of the user (e.g., sip:[email-masked]), and in 
this case, the identity under registration.

A SIP User Agent can only have exactly one ongoing registration for a 
determined SIP Address of Record. This is an excerpt for RFC 3261 that 
  details this case:

"UAs MUST NOT send a new registration (that is, containing new Contact 
header field values, as opposed to a retransmission) until they have 
received a final response from the registrar for the previous one or 
the previous REGISTER request has timed out."

As a conclusion, for the REGISTER request the SIP AOR is more than 
enough for the Diameter server to correlate UAR and MAR.

If we need to extend UAR and MAR to other cases different than 
REGISTER requests (very likely to happen in the future), then we will 
need to put a mechanism to facilitate correlation (this might be as 
simple as including new AVPs for the so-called "tags" in the From and 
To headers in SIP, and the Call-ID header. But this is not required 
for the time being.

> 
> 3.2 SIP server authenticates the user
> 
> [AL] Very little difference between this scenario and the one above. I
> found it uncessary to re-read steps 1 to 12 again. Suggest that you
> truncate this section and talk about the salient differences so we dont
> have to re-read.

Yes, we actually got other similar comments to this section, 
indicating that it was difficult to understand the real meaning and 
the difference, so certainly a rework is needed.

> 
>    An operator with a large base of installed SIP servers may wish to
>    minimize the impact of modifying SIP servers to interact with
>    Diameter servers. This can be achieved by allowing SIP servers to
>    retain the functionality of authentication, rather than centralizing
>    this capability in a Diameter server. However, it should be noted
>    that this mode will not leverage the extensive array of
>    authentication and authorization services which will already be
>    present regardless in Diameter servers.
> 
> [AL] I think you want to say an *existing* installed based. Because new
> deployements would probably not have the SIP server do the
> authentication for the reasons you mention.

ok

>    
> .............
> 
>    When the SIP server 1 receives a next SIP REGISTER request containing
>    the user credentials (step 9), as the SIP server 1 does not need to
>    keep a state (even there is no guarantee that the SIP request arrives
>    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).
> 
> [AL] Change "When the SIP server 1" to: "When SIP server 1" above.

ok

> 
> 
>    SIP server 1 will then forward the SIP REGISTER request to SIP server
>    2 (step 12). SIP server 2 will validate the credentials, and will
>    send a Diameter Server-Assignment-Request (SAR) message (step 13)
>    requesting the Diameter server to store the SIP or SIPS URI of the
>    SIP server that is currently serving the user. The Diameter SAR
>    message also serves the purpose to request the Diameter server to
>    send the user profile to the SIP server. The Diameter server will
>    respond with a Diameter Server-Assignment-Answer (SAA) message (step
>    14). If the Result-Code AVP value does not inform about an error, the
>    User-Data AVP will contain the information that SIP server 2 needs in
>    order to provide a service to the user.
> 
>    The SIP server 2 will generate then a SIP 200 (OK) response (step 15)
>    that will be forwarded to SIP server 1 and eventually to the SIP UAC
>    (step 16).
> 
> [AL] Change "The SIP server 2 will generate then a" to "SIP server 2
> generates a" above.

ok

> 
> 3.3 Session attempt
> 
>    Figure 4 shows the scenario where the SIP server 1 receives a SIP
>    INVITE request (step 1). The SIP server 1 needs to find the address
>    of the SIP server 2, which is serving the addressed UA. Therefore,
>    the Diameter client in SIP server 1 sends Diameter
>    Location-Info-Request (LIR) message (step 2) to the Diameter server.
>    The Diameter server responds with a Diameter Location-Info-Answer
>    (LIA) message (step 3) that contains the SIP or SIPS URI of the SIP
>    server 2. SIP server 1 then forwards the SIP INVITE to SIP server 2
>    (step 4). SIP server 2 will eventually forward the SIP INVITE to the
>    appropriate UAS (step 5).
>    
> [AL] Change "where the SIP server 1 receives" to "where SIP server 1
> receives" above. 
> [AL] Change "The SIP server 1 needs to" to "SIP Server
> 1 needs to"

ok

> 
>              +--------+           +--------+         +--------+
>              |  SIP   |           |Diameter|         |  SIP   |
>              |server 1|           | server |         |server 2|
>              +--------+           +--------+         +--------+
>                   |                   |                   |
>    1. SIP INVITE  |                   |                   |
> 
> 
> 
> Garcia-Martin, et al.    Expires December 15, 2003             [Page 10]
> 
> Internet-Draft      Diameter Multimedia application            June 2003
> 
> 
>    -------------->|     2. LIR        |                   |
>                   |------------------>|                   |
>                   |     3. LIA        |                   |
>                   |<------------------|                   |
>                   |           4. SIP INVITE               |
>                   |-------------------------------------->|
>                   |                   |                   | 5. SIP INVITE
>                   |                   |                   |-------------->
>                   |                   |                   |
>                   |                   |                   |
> 
>                                 Figure 4
> 
>    Although the example shows the connection between a SIP INVITE
>    request and the Diameter LIR message, any other SIP request (such as
>    SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter message.
> 
> [AL] So from the above par. I get that a SIP REGISTER will generate a
> Diameter LIR message. Is that true?

Obviously not. The text should read "any other SIP request except 
REGISTER (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same 
Diameter message".

> 
> 3.4 Update of the user profile
> 
>    The Diameter Multimedia application provides a mechanism for a
>    Diameter server to asynchronously download a user profile to a SIP
>    server whenever there is an update of such user profile. It must be
>    noted that the Diameter server also attaches the user profile in the
>    Diameter Server-Assignment-Request (SAR) message. Although this is
>    valid for most of the daily situations, it may happen that the
>    administrator decides to update or modify the user profile for a
>    particular user, due to, e.g., new services made available to the
>    user. This may involve a human intervention in the Diameter server or
>    some mechanism outside the scope of this specification. In this
>    situation, the Diameter server is able to push the new user profile
>    into the SIP server allocated to the user.
> 
> [AL] Change "This may involve a human intervention in the Diameter
> server or some mechanism outside the scope of this specification" to
> "This may involve mechanisms outside the scope of this specification
> such as human intervention in the Diameter server"

ok

>    
> [AL] Change "The scenario is described in Figure 5" to "The scenario is
> illustrated in Figure 5" below.

ok

>    
>    The scenario is described in Figure 5. In case the user profile
>    changes, the Diameter server will send a Diameter
>    Push-Profile-Request (PPR) message (step 1) to the Diameter client in
>    the SIP server allocated to that user (SIP server 2 in the examples).
>    The Diameter PPR message will contain a SIP-User-Data AVP, a
>    User-Name AVP and zero or more SIP-Public-User-Identity AVPs. The
>    presence of the User-Name AVP without any SIP-Public-User-Identity
>    AVPs serves to indicate that the entire user profile (included in the
>    SIP-User-Data AVP) associated with the User-Name AVP is updated. A
>    Diameter PPR message with a User-Name AVP and one or more
>    SIP-Public-User-Identity AVPs serves to indicate that the user
>    profile data associated with each of the SIP-Public-User-Identity
>    AVPs is updated. The Diameter client in SIP server 2 will acknowledge
>    the Diameter PPR message by sending a Diameter Push-Profile-Answer
>    (PPA) message (step 2) to the Diameter server.
> 
> .........
> 
> 3.5 Registration termination
> 
>    Termination of a user registration can be achieved by either of the
>    following three mechanisms:
> 
> [AL] I am having trouble with this because i dont know where or when
> Auth-Session-State AVP is delivered.

The Auth-Session-State AVP is part of the Diameter base specification. 
All the commands in this application include an Auth-Session-State.

> 
>    In the event that NO_STATE_MAINTAINED (i.e., No Diameter user
>    session-id is maintained) has been indicated in a prior
>    Auth-Session-State AVP, termination is handled with a Diameter
>    Session-Termination-Request (STR) message (if it is initiated by the
>    Diameter Client/SIP Proxy) or with a Diameter
>    Registration-Termination-Request (RTR) message (if it is initiated by
>    the Diameter server).
> 
>    On the other hand, if STATE_MAINTAINED has been indicated in a prior
>    Auth-Session-State AVP, the use of Diameter
>    Session-Termination-Request (STR) and Abort-Session-Request (ASR)
>    messages as defined in the base Diameter specification [2] are used
>    to terminate a user registration.
> 
>    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.
> 
> [AL] Move the stuff below to the start of the section.
>  
>    Reasons for terminating a user registration include:
> 
>    o  Expiration of the SIP registration timer in the SIP server.
> 
>    o  Administrative action taken at the Diameter server.
> 
>    o  The SIP UAC generates a SIP REGISTER request setting the Expires
>       header field value to zero or the expires parameter in the Contact
>       header field to zero (e.g., user initiated deregistration).
> 
> 

ok

> 
> 4. Advertising Application Support
> 
>    Diameter nodes conforming to this specification MAY advertise its
>    support by including the Auth-Application-Id AVP in the
>    Capabilities-Exchange-Request and Capabilities-Exchange-Answer
>    commands, according to the  Diameter base protocol [2].
> 
> Avi Lior
> Bridgewater Systems Corporation
> Phone  :          (613) 591-9104 x6417 or (613) 591-6655
> Fax     :          (613) 591-6656
> E-mail  :          [email-masked]
> www.bridgewatersystems.com

Once more, thanks a lot for your comments.

/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