The Diameter Sip Application : General
The Diameter SIP application can be used in a SIP environment where
an interface to a AAA infrastructure is required to authenticate and
authorize the usage of SIP resources. This application provides
support for SIP User Agents and proxies that implement and use HTTP
Digest authentication [RFC2617], which is the authentication
mechanism mandated by SIP [RFC3261]. The application is extensible
and, if need arises, it can be extended to provide support for other
authentication mechanisms or extensions to HTTP Digest authentication
when they occur.
This application provides limited support for accounting services as
follows: the Diameter server is able to provide the addresses of
accounting severs to the Diameter client. Figure 1, below, shows a
general overview of the integration of the SIP architecture with the
AAA architecture.
According to Figure 1, there are one or more SIP User Agents (UAs)
that initiate or terminate SIP traffic through one or more SIP
servers. Both SIP servers implement a Diameter client that supports
the Diameter application described in this specification.
+--------+
UAR/UAA +--->|Diameter|<----+ PPR/PPA
LIR/LIA | | server | | MAR/MAA
| +--------+ | SAR/SAA
| | RTR/RTA
| |
v v
+------+ SIP +--------+ SIP +--------+ SIP +------+
| SIP |<--------->| SIP |<-------->| SIP |<--------->| SIP |
| UA | |server 1| |server 2| | UA |
+------+ +--------+ +--------+ +------+
^ ^
UAR/UAA | |
LIR/LIA | | MAR/MAA
| +--------+ | SAR/SAA
+--->|Diameter|<----+
| SL |
+--------+
Figure 1: Architecture of the Diameter application for SIP
In Figure 1, it can be seen that SIP server 1 sends different
Diameter commands and receives different responses than those sent
and received by SIP server 2. This is because SIP server 1 in
Figure 1 is located at the edge of a network, and its main task is to
locate SIP server 2. SIP server 2 is requesting and receiving
authentication and authorization data from the Diameter server and is
not located at the edge of the network.
This Diameter application assumes that all the data pertaining to a
given user is stored in a single Diameter server. For redundancy
purposes, several Diameter servers can be configured in a redundancy
fashion, in which case all of them keep the data synchronized and
operate externally as a single Diameter server.
With respect to SIP server 1 in Figure 1, the Diameter SIP
application provides support for the existence of a farm of these
servers, typically configured through one or more DNS records that
point to several hosts (this is a typical configuration in common SIP
deployments). There is no requirement for these types of servers to
keep state related to the Diameter SIP application.
The Diameter SIP application provides support for a feature that
allows an administrative domain to provide a collection of SIP
servers 2 (as per Figure 1). Once the user registers for the first
time, one of these SIP servers is selected and all the SIP requests
related to the user are processed by the same SIP server.
The Diameter Subscriber Locator (SL) serves the purpose of locating
the Diameter server that contains the user-related data. Its
functionality is based on the Diameter redirect mechanism and is
further described in Section 6.8.
It should be noted that this document does not mandate any particular
SIP/AAA architecture. However, the Diameter SIP application provides
the functionality needed to accommodate all the different
architectures where SIP and Diameter are used.
The following subsections provide an informative overview of the
Diameter SIP application, its commands, and a possible interaction
with SIP signaling.
6.2. Diameter Server Authenticates the User
This is the generic mechanism to authenticate users. In this
approach, we show an example of an administrative network where the
Diameter server is authenticating SIP user requests. This could be
the case of a medium-size network where the Diameter server is
keeping user records and authenticating SIP requests to perform a
certain transaction. We have chosen to show a SIP REGISTER request
in the example, but the SIP server could request authentication of
any other SIP request.
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP REGISTER | | |
-------------------->| 2. UAR | |
|------------------>| |
| 3. UAA | |
|<------------------| |
| 4. SIP REGISTER |
|-------------------------------------->|
| | 5. MAR |
| |<------------------|
| | 6. MAA |
| |------------------>|
| 7. SIP 401 (Unauthorized) |
8. SIP 401 (Unauth.) |<--------------------------------------|
<--------------------| | |
9. SIP REGISTER | | |
-------------------->| 10. UAR | |
|------------------>| |
| 11. UAA | |
|<------------------| |
| 12. SIP REGISTER |
|-------------------------------------->|
| | 13. MAR |
| |<------------------|
| | 14. MAA |
| |------------------>|
| 15. SIP 200 (OK) |
16. SIP 200 (OK) |<--------------------------------------|
<--------------------| | |
| | 17. SAR |
| |<------------------|
| | 18. SAA |
| |------------------>|
| | |
Figure 2: Authentication performed in the Diameter server
According to Figure 2, a SIP User Agent Client (UAC) sends a SIP
REGISTER request (step 1) to SIP server 1, which receives the SIP
request. In Figure 2, we assume that this SIP server is located at
the edge of the administrative home domain. The Diameter client in
SIP server 1 contacts 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. The
Diameter server answers with a Diameter User-Authorization-Answer
(UAA) message (step 3), which indicates a list of capabilities that
SIP server 1 may use to select an appropriate SIP server (SIP server
2) and/or a SIP or SIPS URI pointing to SIP server 2.
SIP server 1 forwards the SIP REGISTER request (step 4) to an
appropriate SIP server (SIP server 2). Then the Diameter client in
SIP server 2 requests user authentication from the Diameter server by
sending a Diameter Multimedia-Auth-Request (MAR) message (step 5).
This request also serves to make the Diameter server aware of the SIP
or SIPS URI of SIP server 2, so as to return subsequent requests for
the same user to the same SIP server 2. The Diameter server responds
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 also generates a nonce and includes a challenge in
the MAA message. SIP server 2 uses that challenge to map into the
WWW-Authenticate header in the SIP 401 (Unauthorized) response (step
7), which is sent back to SIP server 1 and then to the SIP UAC (step
8).
SIP server 1 receives a next SIP REGISTER request containing the user
credentials (step 9). Note that SIP server 1 does not need to keep a
state, and even more, there is no guarantee that the SIP request
arrives at the same SIP server 1; there could be a farm of SIP
servers 1 operating in redundant configuration. The Diameter client
in SIP server 1 contacts the Diameter server by sending a Diameter
UAR message (step 10) to determine the SIP server allocated to the
user. The Diameter server sends the SIP or SIPS URI of SIP server 2
in a Diameter UAA message (step 11).
Then SIP server 1 forwards the SIP REGISTER request to SIP server 2
(step 12). SIP server 2 extracts the credentials from the SIP
REGISTER request. The Diameter client in SIP server 2 sends those
credentials in a Diameter MAR message (step 13) to the Diameter
server. At this point, the Diameter server is able to authenticate
the user, and upon success, returns a Diameter MAA message (step 14)
with the AVP Result-Code set to the value DIAMETER_SUCCESS.
Then SIP server 2 generates a SIP 200 (OK) response (step 15), which
is forwarded to SIP server 1 and eventually to the SIP UAC (step 16).
If the Diameter client in SIP server 2 is interested in downloading
the user profile information or is required to store the address of
the SIP server in the Diameter server, then the Diameter client sends
a Diameter SAR message (step 17) to the Diameter server. The
Diameter server replies with a Diameter SAA message (step 18) that
contains the requested user profile information and the
acknowledgement of the SIP server address storage. These actions are
needed when the SIP server has to retrieve a user profile used to
provide services to the served user, or when the SIP server keeps a
state for the user, so the Diameter server needs to store the SIP
server's address.
6.3. Delegating Final Authentication Check to the SIP Server
An operator with a large base of installed SIP servers may wish to
minimize the number of round-trips between the Diameter client and
the Diameter server. We provide support for a mechanism where the
Diameter server delegates the final authentication check to the SIP
server, thereby saving a round-trip. Section 14.1 discusses the
security considerations of this scenario.
It must noted that this scenario is not applicable when the Diameter
server is configured to use a session MD5 (MD5-sess) algorithm,
because the Diameter server requires the client nonce to compute the
H(A1) before sending it to the Diameter client. However, the client
nonce might not be available at that time.
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP REGISTER | | |
-------------------->| 2. UAR | |
|------------------>| |
| 3. UAA | |
|<------------------| |
| 4. SIP REGISTER |
|-------------------------------------->|
| | 5. MAR |
| |<------------------|
| | 6. MAA |
| |------------------>|
| 7. SIP 401 (Unauthorized) |
8. SIP 401 (Unauth.) |<--------------------------------------|
<--------------------| | |
9. SIP REGISTER | | |
-------------------->| 10. UAR | |
|------------------>| |
| 11. UAA | |
|<------------------| |
| 12. SIP REGISTER |
|-------------------------------------->|
| | 13. SAR |
| |<------------------|
| | 14. SAA |
| |------------------>|
| 15. SIP 200 (OK) |
16. SIP 200 (OK) |<--------------------------------------|
<--------------------| | |
| | |
Figure 3: Delegation of authentication to the SIP server
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 that of the
3rd Generation Partnership Project (3GPP) IP Multimedia Core Network
Subsystem.
A first SIP server receives a SIP REGISTER request (step 1) whose
target is the home network domain. In Figure 3, we assume that this
SIP server is located at the edge of the administrative home domain.
The Diameter client in this SIP server requests authorization from
the Diameter server to proceed with the registration, by sending a
Diameter User-Authorization-Request (UAR) message (step 2). The
message includes, among other Attribute-Value-Pairs (AVPs), the SIP
Address-Of-Record (AOR) that is included in the SIP REGISTER request.
The Diameter server verifies the SIP AOR and, if it is a valid
defined user in the home network, authorizes the registration to
proceed. The Diameter server responds with a Diameter
User-Authorization-Answer (UAA) message (step 3), which informs the
Diameter client/SIP server about the result of the user
authorization. In case of a successful authorization, the Diameter
UAA message indicates the address of a local SIP server (SIP server 2
in Figure 3) and/or a list of capabilities that SIP server 1 may use
to select an appropriate SIP server 2.
When the authorization is successful, SIP server 1 forwards the SIP
REGISTER request (step 4) to the appropriate SIP server (SIP server
2). The Diameter client in SIP server 2 requests authentication
parameters by sending a Diameter Multimedia-Auth-Request (MAR)
message (step 5) to the Diameter server. This request also makes the
Diameter server aware of the SIP or SIPS URI of SIP server 2, so as
to return subsequent requests of the same user to the same SIP server
2. The Diameter server responds with a Diameter
Multimedia-Auth-Answer (MAA) message (step 6), which includes a nonce
and all the rest of the parameters necessary for the designated
authentication algorithm associated with the user. Among others, the
MAA message includes a Digest-HA1 AVP that contains H(A1) (as defined
in RFC 2617 [RFC2617]), and that allows the Diameter client to
calculate the expected response. Then the Diameter client can
compare this expected response with the response to the challenge
sent from the SIP UA. The absence of the Digest-HA1 AVP in MAA
indicates that authentication and authorization take place in the
Diameter server, as per the scenario described in Section 6.2.
SIP server 2 creates a SIP 401 (Unauthorized) SIP response (step 7)
based on the challenge included in the MAA message, including the
authentication material needed by the SIP User Agent Client (UAC) to
include the appropriate credentials. SIP server 1 forwards the SIP
response to the SIP UAC (step 8).
The SIP server 1 receives the next SIP REGISTER request containing
the user credentials (step 9). Because SIP server 1 does not need to
keep a state (and there is no guarantee that the SIP request arrives
to the same SIP server 1), the Diameter client in SIP server 1
contacts the Diameter server again by sending a Diameter UAR message
(step 10) to determine the SIP server allocated to the user. The
Diameter server sends the SIP or SIPS URI of SIP server 2 in a
Diameter UAA message (step 11).
SIP server 1 forwards the SIP REGISTER request to SIP server 2 (step
12). SIP server 2 validates the credentials by comparing the
response supplied by the SIP UA with the expected response calculated
by the SIP server 2 (based on the H(A1) received from the Diameter
server).
If the credentials are valid, SIP server 2 sends a Diameter
Server-Assignment-Request (SAR) message (step 13) requesting the
Diameter server to confirm the completion of the authentication
procedure and to confirm the SIP or SIPS URI of the SIP server that
is currently serving the user. The Diameter SAR message also serves
the purpose of requesting that the Diameter server send the user
profile to the SIP server. The Diameter server responds with a
Diameter Server-Assignment-Answer (SAA) message (step 14). If the
Result-Code AVP value does not inform SIP Server 2 of an error, the
SAA message can include zero or more SIP-User-Data AVPs containing
the information that SIP server 2 needs in order to provide a service
to the user.
SIP server 2 generates a SIP 200 (OK) response (step 15), which is
forwarded to SIP server 1 and eventually to the SIP UAC (step 16).
6.4. SIP Server Requests Authentication and Authorization
Figure 4 depicts a typical scenario where a stateless SIP proxy
requests authentication information and authorization to a Diameter
server, for the purpose of providing SIP routing services to a SIP
User Agent. The SIP proxy server may be configured as an outbound
SIP proxy, so that all the requests initiated by the SIP UA traverse
the SIP proxy.
According to Figure 4, a SIP User Agent sends a SIP request to its
outbound SIP proxy server. In this case, the message is a SIP INVITE
request (see step 1), but it could be any other SIP request. We
assume that this SIP request does not contain any credentials at this
time. The outbound SIP proxy server needs to authenticate and
authorize the proxy services offered to the user. The Diameter
client in the SIP server sends a Multimedia-Auth-Request (MAR)
message (step 2). The Diameter server generates a nonce and sends a
Multimedia-Auth-Answer (MAA) message (step 3) that includes the nonce
and the rest of the data necessary for the SIP server to challenge
the user, typically with HTTP Digest Authentication indicated in the
MAA message. This data enables the SIP server to create a SIP 407
(Proxy Authentication Required) response (step 4) that contains a
challenge. The SIP UA creates a new INVITE request (step 5) that
contains the credentials. The Diameter client in the SIP server
sends the credentials to the Diameter server in a new Diameter MAR
message (step 6). The Diameter server validates the credentials and
authorize the SIP transaction in a Diameter MAA message (step 7).
The SIP server forwards the SIP INVITE request to its destination
(step 8) as per regular SIP procedures. Eventually, the session
setup is confirmed with a SIP 200 (OK) response (step 9) that is
forwarded to the SIP UA (step 10). The session setup is complete.
+--------+ +--------+
|Diameter| | SIP |
| server | | server |
+--------+ +--------+
| |
| |
1. SIP INVITE |
----------------------------------->|
| 2. MAR |
|<------------------|
| 3. MAA |
|------------------>|
| |
4. SIP 407 (Proxy |
Authentication Required) |
<-----------------------------------|
| |
5. SIP INVITE |
----------------------------------->|
| 6. MAR |
|<------------------|
| 7. MAA |
|------------------>| 8. SIP INVITE
| |---------------->
| | 9. SIP 200 (OK)
10. SIP 200 (OK) |<----------------
<-----------------------------------|
| |
Figure 4: SIP server requests authorization
6.5. Locating the Recipient of the SIP Request
Figure 5 shows the scenario where SIP server 1 may be configured as a
SIP edge proxy server, processing SIP traffic at the edge of a
network. SIP server 1 receives a SIP INVITE request (step 1). SIP
server 1 needs to find the address of SIP server 2, which is serving
the recipient of the SIP request. The Diameter client in SIP server
1 sends a 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 SIP server 2. SIP server 1 then forwards the SIP INVITE
to SIP server 2 (step 4). SIP server 2 eventually forwards the SIP
INVITE to the appropriate UAS (step 5).
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP INVITE | | |
-------------->| 2. LIR | |
|---------------->| |
| 3. LIA | |
|<----------------| |
| 4. SIP INVITE |
|--------------------------------->|
| | | 5. SIP INVITE
| | |-------------->
| | |
| | |
Figure 5: Locating the SIP server of the recipient
Although the example shows the connection between a SIP INVITE
request and the Diameter LIR message, any SIP request other than
REGISTER (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same
Diameter message. (A SIP REGISTER request will trigger a Diameter
UAR message, as indicated in Figure 2 and Figure 3.)
The scenario described in this section is also applicable in case an
outbound SIP server is not interested in authenticating the user, but
is required to locate a further SIP server to route the outbound SIP
requests. In this case, the outbound SIP server is mapped to SIP
server 1 as shown in Figure 5.
6.6. Update of the User Profile
The Diameter SIP 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 to the
Diameter Server-Assignment-Answer (SAA) message. This is valid for
most of the daily situations; however, the administrator may decide
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
mechanisms outside the scope of this specification, such as human
intervention, in the Diameter server. In this situation, the
Diameter server is able to push the new user profile into the SIP
server allocated to the user.
The scenario is illustrated in Figure 6. When the user profile
changes, the Diameter server sends 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 contains one or more SIP-User-Data AVPs, a User-Name AVP
and zero or more SIP-AOR AVPs. The Diameter client in SIP server 2
acknowledges the Diameter PPR message by sending a Diameter
Push-Profile-Answer (PPA) message (step 2) to the Diameter server.
+--------+ +--------+
|Diameter| | SIP |
| server | |server 2|
+--------+ +--------+
| |
| 1. PPR |
|------------------>|
| |
| 2. PPA |
|<------------------|
| |
Figure 6: Diameter server pushes an update of the user profile
6.7. SIP Soft State Termination
SIP can create soft states in SIP nodes based on events such as SIP
registrations or SIP event subscriptions. These states are
periodically refreshed, and cease to exist if they are not refreshed.
Additionally, an administrative action can be taken to terminate a
SIP soft state, or the SIP UA can explicitly terminate a SIP soft
state.
The Diameter base protocol offers a mechanism to create and delete
states in Diameter nodes. These states are called Diameter user
sessions. The Diameter server decides whether to use a Diameter user
session as a mechanism to map to a SIP soft state. If the Diameter
server decides to use Diameter user sessions, the termination of a
Diameter user session implies the termination of the corresponding
SIP soft state (e.g., registration, event subscription), and vice
versa. If the Diameter server does not use Diameter user sessions,
this Diameter SIP application offers specific commands to manage the
SIP soft states. Implementations compliant with this specification
MUST support both mechanisms of session management.
We provide support for both Diameter client- and Diameter
server-initiated session termination. Depending on whether Diameter
sessions are used, termination of a SIP soft state can be achieved by
one of the following methods:
o When the Diameter client (SIP proxy) wants to terminate the SIP
soft state and Diameter user sessions are not maintained (i.e.,
the Auth-Session-State AVP has been previously set to
NO_STATE_MAINTAINED), the Diameter client MUST send a
Server-Assignment-Request (SAR) message with the
SIP-Server-Assignment-Type AVP (Section 9.4) set to any of the
deregistration values: TIMEOUT_DEREGISTRATION,
USER_DEREGISTRATION, TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME,
USER_DEREGISTRATION_STORE_SERVER_NAME,
ADMINISTRATIVE_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA.
o When the Diameter client (SIP proxy) wants to terminate the SIP
soft state and Diameter user sessions are maintained (i.e., the
Auth-Session-State AVP has been previously set to
STATE_MAINTAINED), the Diameter client MUST send a Session-
Termination-Request (STR) message as per regular procedures
according to RFC 3588 [RFC3588].
o When the Diameter server wants to terminate the SIP soft state and
Diameter user sessions are not maintained (i.e., the
Auth-Session-State AVP has been previously set to
NO_STATE_MAINTAINED), the Diameter server MUST send a
Registration-Termination-Request (RTR) message (see Section 8.9).
o When the Diameter server wants to terminate the SIP soft state and
Diameter user sessions are maintained (i.e., the
Auth-Session-State AVP has been previously set to
STATE_MAINTAINED), the Diameter server MUST send an
Abort-Session-Request (ASR) message as per regular procedures
according to RFC 3588 [RFC3588].
6.8. Diameter Server Discovery
The basic architecture assumption of this document is that all the
data related to a user is stored in a unique Diameter server.
Contrary to general opinion, this does not create a single point of
failure. It is assumed that Diameter servers are configured in a
redundant fashion in an attempt to mitigate the
single-point-of-failure problem.
In large networks, where the number of users may be significantly
high, there might be a need to scale the number of Diameter servers.
All the data associated with a user is still stored in one Diameter
server (typically, operating in a redundant configuration), but the
data associated with different users may reside in different Diameter
servers.
Although this configuration scales well, it introduces a new problem,
namely: given the user's SIP AOR as an input, how to determine which
of various Diameter servers is storing the data for that particular
SIP AOR. We solve this problem with inspiration from the Diameter
redirection mechanism specified in RFC 3588 [RFC3588]. We include in
the architecture a new Diameter node that, for the purpose of this
document, is known as Diameter Subscriber Locator (SL). The Diameter
SL contains a database or routing tables that map SIP AORs to
Diameter server URIs. A particular Diameter server URI points to the
actual Diameter server that stores all the data related to a
particular SIP AOR, and in consequence, to the user who owns the SIP
AOR. The Diameter SL acts in a similar way to a Diameter Redirect
Agent, dispatching Diameter requests (e.g., providing the redirection
URI in the answer). The Diameter SL can redirect all the request
pertaining to a user by setting the Redirect-Host-Usage AVP with a
value ALL_USER, as specified in RFC 3588 [RFC3588].
The Diameter SL can be replicated in different nodes along the
network, for the purpose of building scalability and redundancy. The
database or routing tables have to be consistent across all these
different Diameter SLs, so that equal Diameter requests will produce
equal Diameter answers, no matter which Diameter SL processes the
request.
+--------+ +--------+ +--------+ +--------+
| SIP | |Diameter| |Diameter| | SIP |
|server 1| |SL red. | |server 1| |server 2|
+--------+ +--------+ +--------+ +--------+
| | | |
1. SIP INVITE| | | |
------------>| 2. LIR | | |
|---------->| | |
| 3. LIA | | |
|<----------| | |
| 4. LIR | |
|---------------------->| |
| 5. LIA | |
|<----------------------| |
| 6. SIP INVITE | |
|----------------------------------->| 7. SIP INVITE
| | | | ------------->
| | | |
Figure 7: Locating a Diameter server. SL redirecting requests
Figure 7 shows an example of operation of a Diameter SL acting in
redirect mode. SIP server 1 receives an INVITE request (step 1)
addressed (in the SIP Request-URI) to a user for which the Diameter
client in SIP server 1 does not possess routing information. In
other words, the Diameter client in SIP server 1 does not know the
URI of the Diameter server 1. The Diameter client sends a Diameter
LIR message (step 2) to any of the Diameter SLs configured in the
network. The address of those SLs is assumed to be pre-provisioned
in the Diameter client. The Diameter SL, based on the contents of
the SIP-AOR AVP and its own routing tables, determines the Diameter
server that stores the information allocated to such user. Then it
builds a Diameter LIA message (step 3) that includes a Result-Code
AVP set to DIAMETER_REDIRECT_INDICATION and one Redirect-Host AVP,
whose value is set to the URI of the Diameter server that stores the
information related to such user. Then the Diameter client in SIP
server 1 builds a new LIR message (step 4) addressed to the Diameter
server received in the Redirect-Host AVP. The rest of the procedure
is completed as described in previous sections.
