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

From: Avi Lior <[email-masked]>
Date: Thu, 31 Jul 2003 11:48:06 -0400

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.....

   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
   
   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"

   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?

.....

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.

   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?
   
   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?
   
   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.
  
[AL] What subsequent requests? Why wouldnt subsequent commands go
directly to SIP2?

[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.
   
   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 ;-)
 
   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?

   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?

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.

   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.
   
.............

   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.

   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.

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"

             +--------+           +--------+         +--------+
             |  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?

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"
   
[AL] Change "The scenario is described in Figure 5" to "The scenario is
illustrated in Figure 5" below.
   
   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.

   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).

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