New RFC-6733 (Diameter Base Protocol)

New RFC for Diameter Base Protocol is released.


Obsoletes: 3588, 5719  

Other than typo error following differences have been identified.



Major Differences


Sr. No.
RFC-3588
RFC-6733
Usage of IP-Sec
1.
IP-Sec Support is required for secured communication within the Realm(Intra-Realm)
IP-Sec support for diameter is not required, If diameter node communicates on TCP should support TLS and on SCTP should support DTLS.
Default Ports
2.
Default Port is 3868
Default port for TCP and SCTP is 3868 and Port of TLS and DTLS is 5868.
Security On CER
3.
In 3588 CER/CEA message is used to know whether to establish TLS channel (secure transport) using INBAND-SECURITY AVP.
Now in 6733, TLS channel is to be established if security to be applied before CER/CEA message that shall also make CER/CEA message secure.

Explanation
Now in RFC-6733, it is specified that whether to use secure channel or not to use is to be decided at the time of Transport-Connection (i.e. when TCP or SCTP connections are created) not after CER. Because of this if security channel to be applied (TLS or DTLS) the CER/CEA shall also be secured because Transport connection is established before the diameter connection.
Usage of Application Id
4.
Doesn’t clearly state about the usage of Application Id in session based application and base DIAMETER messages.
In RFC-6733 it is clearly stated that Diameter messages related to sessions, both application-specific and those defined in Base Diameter such as ASR/ASA, RAR/RAA and STR/STA MUST have Application Id of the application. Diameter messages pertaining to peer connection establishment and maintenance  such as CER/CEA, DWR/DWA MUST have Application Id set to ZERO (0)

For Example
Implies if two nodes communicate on session bases application X   with application ID 12345 (say), must publish the application Id 12345 for all session based messages such as ASR/ASA, RAR/RAA and STR/STA, Although these messages are of Base-Diameter. And all   the messages that are communicated between two nodes(can't be    relayed, proxy) shall have Application Id set to ZERO instead of 12345
Message Length
5.
Doesn’t clearly state about Message Length.
The Message Length field is three octet and indicates the length of Diameter message including the header field and the padded AVPs. Thus, the Message Length field is always a multiple of 4.
Usage of Inband-Security AVP
6.
Inband-Security AVP shall be used to tell whether to use TLS or not in CER/CEA message.
Now in RFC-6733, Inband-Security AVP is deprecated, because when secure channel to be use then notification of this shall be      communicate at the time of Transport Connection (i.e. before CER/CEA message) as stated in point-2.
Capability Update Request
7.
No Mechanism of Capability Update.
As CER/CEA message shall be sent once at the time of Application Layer connection initiation (when diameter connection is to be established.)
Now RFC-6733 provides a mechanism when CER/CEA message can be exchanged during established DIAMETER Connection.
Auth-Application-Id is 10 when CER/CEA is exchanged during established connection.
Security mechanism can’t be changed with the help of Capability Update Request (CER/CEA with Application Id 10.)

For Example.
There are two nodes Node-A and Node-B where Node-A supports App-1 and App-2 while Node-B supports App-1 only. These nodes shall exchange their common Application ID “App-1” in CER/CEA message. Now Node-B is to be upgraded where it can also support App-2 so there is no need to break the diameter/transport connection to tell Node-A about “App-2”. Here in this case Node-B shall trigger the CER with supported applications “App-1” and “App-2” with Auth-Application-Id set to 10.
Usage of E2E-Sequence AVP
8.
E2E-Sequence AVP is used to protect replay attaches. It is used to identify Each message uniquely and MUST be included when end to end protection is applied.
Use of E2E-Sequence AVP is deprecated. End to End security is ensured with TLS/TCP and DTLS/SCTP.
Explanation on Redirect-Host-Usage AVP
9.
No explanation, when multiple cache routes are created that differs only in redirect usage and peers to forward requests.
Now RFC-6733 provides a priority rule for multiple cache routes. That tells which entry to use. Rule as follow.
1.  ALL_SESSION
2.  ALL_USER
3.  REALM_AND_APPLICATION
4.  ALL_REALM
5.  ALL_APPLICATION
6.  ALL_HOST
Diameter Identity
10.
DiameterIdentity  =  FQDN
DiameterIdentity  =  FQDN/Realm
DiameterIdentity must use ASCII character only so that it complies with DNS.
Loop Detection
11.
Here only loop detection mechanism is explained, Nothing is given for avoidance or recovery from loop.
RFC-6733 clearly states about loop avoidance or recovery. Here Node that detects loop may attempt for alternative route if exists. If all the alternative routes are tried then it shall return DIAMETER_UNABLE_TO_DELIVER message.
Command Code Format Specification
12.
command-def =
command-name "::=" diameter-message
command-def="<"command-name">" "::=" 
          diameter-message




Your Comments /Suggestions and Questions are always welcome, shall clarify with best of knowledge. So feel free to put Questions

27 comments:

  1. Really a very good distinguish explanation between older RFC and newer RFC

    ReplyDelete
  2. Thank you, this helps a lot..

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Hi, I have a query. Pls provide your comments.

    What are the differences between ASR and RAR messages?

    I could not get enuf information from any web searches. Thanks in advance.

    Regards,
    Karthik

    ReplyDelete
  5. Hi Karthik

    Both messages are used when session is maintain between client and server. Moreover both the messages are triggered by server.

    In RAR (Re-Auth-Requset)server is asking the client to authenticate himself again as a time of authenticated session is elapse; this time value is exchanged between them in earlier messages. Same session continues until RAR sends -ve response in RAA. If server sent RAA with DIAMETER_SUCCESS then same session continues for already fixed time, and as per the requirement RAR can come again to authenticate session as fixed authentication Time come to an end. There is concept of grace time as well. Grace Time is time till sever waits for RAA.

    While ASR (Abort-Session-Request)is the intimation that session is going to be dropped by server, Some time server don't wait for ASA.


    There is another message STR (Session-Termination-Request), It is triggered by Client, to tell that current session comes to an END.


    I hope information shared shall help you.

    ReplyDelete
    Replies
    1. Hi Dinesh,

      Many thanks for the info. I have some more doubts.

      1. Can RAR be used only in case of MSCC (Multiple Service Credit-control)?

      Delete
    2. Hi Karthik,

      1.RAR/RAA messages are part of Gx and Gy interface. In Gy message interface mostly when user's balance is insufficient or out of balance in that scenario Credit-Control server will send Credit Re-Authorization request.Requesting the user to have sufficient balance in order to cover the intended service expense.
      For more information please refer https://tools.ietf.org/html/rfc4006

      2. In Gx interface there are number of reasons in order to make a Re-Authorization request. When ReValidation Time Out happens, SGSN-IP got changed, QoS Changed etc. For more detail you can refer 3GPP spec 29.212 http://www.etsi.org/deliver/etsi_ts/129200_129299/129212/11.06.00_60/ts_129212v110600p.pdf , Please refer the section 5.3.7 which desscribe about Event-Trigger AVP mainly responsible for RAR message.

      I hope the above information will help you.

      Delete
  6. Hi,
    I had a query.
    What should be the value of application id when a Diameter relay agent responds to a CER with a CEA message?
    Should it be '0xffffffff' or '0' ?

    -Sayan

    ReplyDelete
    Replies
    1. Hi Sayan

      Both CER-CEA shall advertise '0xffffffff' in Application-ID related AVP


      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
    2. Hi Team-Diameter,

      Thanks a lot for the response.
      So the Application Id field remains as '0' in case of a Diameter relay agent?

      - Sayan

      Delete
    3. Application ID in Header field should be set to ZERO.

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
    4. Thanks Team-Diameter !!!
      Really appreciate your prompt responses

      Delete
  7. Hi Team-Diameter,

    Thanks .It is a very good information.

    I had query : What is diference between Diameter Messages and Diameter Command Code ?

    ReplyDelete
    Replies
    1. Hi Vinayak,

      I simplest of form, Diameter Message is human readable for of Diameter Command Code.

      Diameter Command Code (Unsigned Integer )is the value that travels over Network to rather than Diameter Message name, it is efficient to sent Unsigned Integer over network than a character string.

      such as Diameter-Watchdog-Request [Diameter Message] -- 280 [Diameter Command Code]

      Thanks for your query

      Happy to help you again.
      Team-Diameter

      Delete
  8. Hi Team-Diameter,

    Thanks for such a nice explanation.
    Here is a couple of questions for you:

    1. I dint find much information on the usage of App-Id. Can a client assign any value for app-id or is it something that's provided by IEEE or any standardization. Could you explain it in detail.

    2. RFC says CER/CEA, DWR/DWA, CUR/CUA must be communicated directly between dia clients/servers. But what if there is a proxy/relay/redirect agent existing between the clients (or client-server).

    ReplyDelete
    Replies
    1. Hi Pattnaik,

      1) Application Id is provided by Standardization Body. Application Id is used in various places here we are sharing you two major usage of Application ID
      a) Capability Negotiation
      http://diameter-protocol.blogspot.in/2011/03/capability-negotiation.html
      b) Realm Table
      http://diameter-protocol.blogspot.in/2012/06/realm-based-routing-table.html

      2) YES, Above mentioned messages neither Proxed or Relayed/Redirected. These are communicated between two immediate peers only.

      For instance if Relay is in between of client and server then CER/DWR shall be exchanged between [RELAY and Client]..... and [Relay and Server] both activities are independent in nature and no session.


      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  9. Hi

    I want to know the complete inforamtion of AgeOfLocationInformation attribute which is being used to send in UDA response.

    AgeOfLocationInformation = 0 means ?
    AgeOfLocationInformation = 1 means ?

    I searched in the 3GPP TS docs but I Could not get the detailed information.

    ReplyDelete
    Replies
    1. Hi Naveen Kumar,

      0-1 is the possible values of cardinality of entity AgeOfLocationInformation, i.e occurrence of entity AgeOfLocationInformation could be zero or one in message format.

      AgeOfLocationInformation can contain any value from range [>=0 ,<=32767 ] of type interger, representing time in minutes.


      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  10. The security parameter exchange/handshake (for TLS or DTLS) also happens after CER/CEA - as per RFC 6733 if the peer is already in OPEN state.
    See the text from RFC 6733 (Section : 13):
    "For TLS/TCP and DTLS/SCTP connections to be established in the open state, the CER/CEA exchange MUST include an Inband-Security-ID AVP with a value of TLS/TCP and DTLS/SCTP. The TLS/TCP and DTLS/SCTP handshake will begin when both ends successfully reach the open state, after completion of the CER/CEA exchange."

    ReplyDelete
    Replies
    1. Hi Gaurav,

      Thanks for highlighting this statement. In first go it looks quite confusing, but statement is correct and well intended too. (But in English literature statements written like this "open state, after " comma making point correct)

      Node reaches to open state when both ends successfully performs the TLS/TCP and DTLS/SCTP handshake and completes CER/CEA exchange.

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  11. Hi , Should CER have Vendor specific application with vendor -id as 10415 with Auth Application id as 16777264 for SWm interface ? or it should have only auth application id as 16777264without vendor id.?

    ReplyDelete
    Replies
    1. Hi

      Vendor specific application AVP Format is as follow

      ::= < AVP Header: 260 >
      ----Mandatory AVP----> { Vendor-Id }
      [ Auth-Application-Id ]
      [ Acct-Application-Id ]

      Vendor ID is a Mandatory Element of AVP structure hence it must send Vendor ID 10415. 10415 is assigned to 3gpp.

      Hope it suffice your query.

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  12. Hi , Great blog ! thank you .
    I have a question regarding understanding the DICTIONARY format (RTF 6733)

    What is meant by the asterisks before the AVP definition ?

    Multiple-Services-Credit-Control ::= < AVP Header: 456 >
    [ Granted-Service-Unit ]
    [ Requested-Service-Unit ]
    *[ Used-Service-Unit ]
    [ Tariff-Change-Usage ]
    *[ Service-Identifier ]
    [ Rating-Group ]
    *[ G-S-U-Pool-Reference ]
    [ Validity-Time ]
    [ Result-Code ]
    [ Final-Unit-Indication ]
    *[ AVP ]

    Thanks

    Golan

    ReplyDelete
    Replies
    1. Hi Golan,

      The operator "*" preceding an element indicates repetition.

      [] -> Optional
      {} -> Multiple
      *n[] -> optional and n repetitions
      *[] -> Optional and unlimited repetitions

      Thanks for your query.

      Delete
  13. Can somebody share some content for various interfaces (like gx, Gy ....) involved in SIP - Diameter communication.

    ReplyDelete
  14. Hi, can you provide a pdf file on whole diameter discussed here?
    my email id is: ece.1005431119@gmail.com

    ReplyDelete