top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Diameter : What is the difference between rfc 3588 and 6733 ?

+3 votes
1,686 views

Both the RFCs are referred for Diameter protocol. I want to know why two RFCs are defined for same Diameter protocol ? Difference between these two RFCs in term of contents ?

posted Aug 16, 2016 by Ganesh

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

Hi Ganesh

The main diffrence between these two RFCs are

  1. In 3588 CER/CEA message is used to know whether to establish TLS channel (secure transport) using INBAND-SECURITY AVP.
    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.

  2. rfc 3588 Doesn’t clearly state about the usage of Application Id in session based application and base DIAMETER messages.
    In rfc 6733 if two nodes communicate on session base 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.

  3. In 3588 No Mechanism of Capability Update is specified.
    RFC-6733 provides a mechanism when CER/CEA message can be exchanged during established DIAMETER Connection.

    for more details refer to below link:
    http://diameter-protocol.blogspot.in/2013/02/blog-post.html

answer Aug 25, 2016 by Lavanya L
Similar Questions
+3 votes
SCTP guidelines for Diameter base protocol specified in section 2.1.1 of RFC 6733

I have a query on SCTP guidelines for Diameter base protocol specified in section 2.1.1 of RFC 6733 as :

"A Diameter agent SHOULD use dedicated payload protocol identifiers (PPIDs) for clear text and encrypted SCTP DATA chunks instead of only using the unspecified payload protocol identifier (value 0). For this purpose, two PPID values are allocated: the PPID value 46 is for Diameter messages in clear text SCTP DATA chunks, and the PPID value 47 is for Diameter messages in protected DTLS/SCTP DATA chunks."

RFC doesn't specify the behavior if the connected diameter peer doesn't use PPID as 46/47 for diameter message transport over SCTP or DTLS/SCTP. What if diameter messages are received with PPID set to value other than 46/47 or default 0 value? Should the messages be ignored or respond with error diameter message back to peer with same PPID set ? Please comment on this behavior.

+1 vote
Diameter questions regarding RFC 3539

I am studying RFC 3539. While I have some difficulties to understand "Appendix A - Detailed Watchdog Algorithm". Please provide some help.

1) Does AAA client or AAA Server (direct connection scenario) need to follow the algorithm?
In section 3.4 we have: "The watchdog is used in order to enable a AAA client or agent to determine when to resend on another connection." Does it mean the algorithm is only required in AAA client? Without following the algorithm AAA server would utilize the newly connected link earlier than AAA client, which would cause some AAA server initiated procedures, such as RAR, result in failure.

2) If the algorithm is required in AAA server, how to avoid the infinite loop when both AAA client and AAA server enter "REOPEN" phase?
If the "connection up" event indicates to AAA client and AAA server, both of them would send DWR to verify the link and enter "REOPEN" phase. While in this phase only DWA is allowed to be a signal to trigger the state machine going forward. It seems to me that both sides would discard the DWR sent by their peer and run into an infinite loop.

3) If the DWR was out of the scope of Non-DWA, how to avoid the inconsistent states between 2 AAA peers?
The total link verification time by the algorithm would be 2 x Tw + 3 x (time of DWA - time of DWR). If one side sets its Tw much longer than the other, it would run into the similar consequence of my question 1) - one side would utilize the newly connected link earlier than the other.

4) Is RFC 3539 so strictly binding to RFC 3588?
RFC 3588 has many statements referring to RFC 3539, especially in its transport description. I am quite confused about the coordination between the state machine logic in the Section 5.6 of RFC 3588 and that in the Appendix A of RFC 3539. I am wondering the strong binding is necessary to the application of AAA or very diameter application.

...