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

From: Benoit Claise <[email-masked]>
Date: Fri, 11 Aug 2017 11:05:05 +0200

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 <[email-masked]>
To: 	[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked]
CC: 	[email-masked], [email-masked], [email-masked]

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 <[email-masked]>

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
.

---

From: "Mark Jones" <[email-masked]>
Date: Sun, 13 Aug 2017 18:26:02 -0400

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:[email-masked]] On Behalf Of Benoit Claise
Sent: August 11, 2017 05:05
To: [email-masked]; [email-masked]
Subject: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 (5084)

Regards, Benoit

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

Subject: 

[Technical Errata Reported] RFC6733 (5084)

Date: 

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

From: 

RFC Errata System  <mailto:[email-masked]> <[email-masked]>

To: 

[email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

CC: 

[email-masked], [email-masked], [email-masked]

 
--------------------------------------
Type: Technical
Reported by: Priyatosh Mandal  <mailto:[email-masked]> <[email-masked]>
 
Section: 8.16
 
Original Text
-------------

Corrected Text
--------------
 
Notes
-----

Instructions:
-------------