New RFC-6733 (Diameter Base Protocol)

New RFC for Diameter Base Protocol is released.

Request for Comments: 6733 

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