Subject: [Dime] [rfc3588bis] Diameter version in diameter header

From: Sebastien Decugis <[email-masked]>
Date: Wed, 09 Jul 2008 10:53:16 +0900

Hello list,

I think the description of the Diameter Version field in the Diameter 
Header (section 3) is incomplete, or at least unclear. More guidelines 
would be needed in the text on how to handle a message with a different 
version number. In particular, I have read in previous mail exchanges 
that an answer should be sent with the same command-code and Result-Code 
AVP set to DIAMETER_UNSUPPORTED_VERSION (5011). This assumes that the 
implementation is able to extract at least the command-code and the 'R' 
flag from the message of unsupported version, to create the answer. So 
my question: what is supposed to be common to all Diameter future 
versions in the message header? Does the version number increments only 
when a new flag is defined?

I would think that clarifying this part could be handled inside the 
current effort on extensibility.

Do you have any thoughts?

Thank you,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Biplab Sarkar <[email-masked]>
Date: Wed, 09 Jul 2008 11:39:26 +0530

Hi All,

I believe between a pair of peers, some minimum version for
communication has to be decided during the
message exchange. This can be trivially done. A minimal message header
needs to be ensured across all future diameter message
versions. And this needs to be explicitly captured in the document.  

Thanks & Regards
Biplab

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 8 Jul 2008 23:52:53 -0700

Sebastien Decugis [mailto://[email-masked]] writes:

> AVP set to DIAMETER_UNSUPPORTED_VERSION (5011). 

What is unclear about that?

> This assumes that the
> flag from the message of unsupported version, to create the answer. 

In other words, the message must be recognizable by the receiving peer as a
Diameter message.  This seems fairly reasonable to me.

> So my question: what is supposed to be common to all Diameter future

Section 4.3 of RFC 3588 says: "In the event that a new Basic AVP Data Format
is needed, a new version of this RFC must be created."  Since this RFC is
the defining document for the Diameter protocol, presumably this would also
cause the version number in the header to be incremented.  As you point out,
however, this should probably be expanded to mention changes to the base
protocol header, and it might be nice to highlight which parts of the header
must remain stable in order for the protocol to be called Diameter.

...

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 09 Jul 2008 16:38:26 +0900

>> an answer should be sent with the same command-code and Result-
>> Code AVP set to DIAMETER_UNSUPPORTED_VERSION (5011). 
>>     
>
Nothing, sorry I am not native English speaker so my sentence was 
probably confusing. The unclear part was what follows...
> Diameter message.  This seems fairly reasonable to me.
Yes, you are right, the length of the message must also be correct. 
Therefore the implementation must be able to interpret at minimum the 
first two bytes of the message -- with the exception of the "(r)eserved" 
flags which can be ignored.
> cause the version number in the header to be incremented.
I don't understand this remark. The data format is not explicitly 
included in the message, it is implied by the AVP code. Therefore even 
if a new AVP is defined with a new data format, it will not change at 
all the format of the message, so there would be no need to change the 
version number...
The implementation is either capable of handling the AVP (and therefore 
its new base type) or not, with the consequences that are described in 
the document (depending on the 'M' flag value of the AVP).
>   As you point out,
Thank you :)

In order to go forward, I would like to mention this also:
Correct me if I am wrong, but an exchange with a peer always begins with 
a CER/CEA exchange. Therefore, the message received with a mismatching 
Diameter version information is supposed to be a CER. As Biplab 
mentions, it would be trivial to force the CER header format and 
negotiate the protocol version during this exchange (with a dedicated 
AVP for example).

After a successful CER/CEA exchange (with correct version number), if a 
message is received with an unsupported version, I think it would be 
better to simply discard the message and close the transport connection. 
It may mean that the security layer is misbehaving, or that message 
boundaries were losts, or any other (probably) unrecoverable error. 
Trying to create an answer with a 5011 Result-Code from a message which 
is probably trash seems broken design to me...

Any more thoughts?

Thanks,
Sebastien.