Re: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 (5084)

["Mark Jones" <[e-mail]>]

Hi Benoit,

 

I agree that the Origin-State-Id rollover behaviour is undefined but the proposed fix is incorrect. The clause immediately before the proposed addition reserves an Origin-State-Id value of zero for use by an access device that does not intend for a state loss inference to be made.
 
The proposed addition also only handles an implementation using an incrementing counter but the RFC permits other schemes. The only normative text I could find was “A Diameter entity issuing this AVP MUST create a higher value for this AVP each time its state is reset” (section 8.16). 
 
Using the device startup (epoch) time as Origin-State-Id is also suggested (as a MAY) but it exposes the good ole Y2038 problem. I imagine there are lots of RFCs where event timestamps are of type time_t. Is a Y2038 audit already planned in the IETF? Perhaps this issue can be tackled at that time.

 

./Mark

 

From: AAA-DOCTORS [mailto:[e-mail]] On Behalf Of Benoit Claise
Sent: August 11, 2017 05:05
To: [e-mail]; [e-mail]
Subject: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 (5084)

 

What do you guys think of this errata?

Regards, Benoit



-------- Forwarded Message -------- 


Subject: 

[Technical Errata Reported] RFC6733 (5084)


Date: 

Thu, 10 Aug 2017 21:04:56 -0700


From: 

RFC Errata System  <mailto:[e-mail]> <[e-mail]>


To: 

[e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]


CC: 

[e-mail], [e-mail], [e-mail]

 

The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5084
 
--------------------------------------
Type: Technical
Reported by: Priyatosh Mandal  <mailto:[e-mail]> <[e-mail]>
 
Section: 8.16
 
Original Text
-------------
By including Origin-State-Id in a message, it allows other Diameter
entities to infer that sessions associated with a lower Origin-State-Id 
are no longer active.
If an access device does not intend for such inferences to be made, it 
MUST either not include Origin-State-Id in any message or set its value 
to 0.
 
 
 
Corrected Text
--------------
By including Origin-State-Id in a message, it allows other Diameter
entities to infer that sessions associated with a lower Origin-State-Id 
are no longer active.
If an access device does not intend for such inferences to be made, it 
MUST either not include Origin-State-Id in any message or set its value 
to 0. 
As a special case when the value of Origin-State-Id changes from 
4294967295 to 0, then also the access device  clear all the sessions.
 
Notes
-----
Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the maximum 
value it can have is 4294967295. If the system restarts many times and the value of
Origin-State-Id reaches the value which is same as its maximum value 4294967295. 
Then what will happen for the next restart. At the next restart the value of Origin-State-Id 
will be 0 if we try to increase the value of Origin-State-Id.
It is not defined in the RFC 6733, that how the system should behave after 4294967295-th 
restart with respect to Origin-State-Id.
 
Generally when the peer receives an increased value of Origin-State-Id, then it clear all sessions.
If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then after another restart 
its value will be 0. For a special case for transition of value of Origin-State-Id from 
4294967295 to 0, the peer should clear its session.
 
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 
 
--------------------------------------
RFC6733 (draft-ietf-dime-rfc3588bis-33)
--------------------------------------
Title               : Diameter Base Protocol
Publication Date    : October 2012
Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
.