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

"Mark Jones" <> Sun, 13 August 2017 22:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74850133077 for <>; Sun, 13 Aug 2017 15:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id umQ59vAsOY8A for <>; Sun, 13 Aug 2017 15:26:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82EF01333E9 for <>; Sun, 13 Aug 2017 15:26:04 -0700 (PDT)
Received: by with SMTP id h70so6617168ioi.2 for <>; Sun, 13 Aug 2017 15:26:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=xfTR70zfndBehhefaoa9/t89dlmQpjwq/T4ehv3iQSA=; b=AdVHAEuE+Ws0gWMerKCpTK8mA19LleS/wsGw4DVnCl20QiNgGVwZ/5nAY9gEeYj+Xk Kft6V8i2sNQTj+Sc/e1QZ8QTlaZ/P549mmnHpUoTz6XSKEErYKSec41GPIGYuBs64O7o jZmgIxCj4s6w7iNAJn1DVSgqYikX9/eI8VNozvBNDfnrXqaGf5DJ3+Dz/ONs+inGwfeR 6Tdd0Do0p20a4XQ+Opt6ndEwiRmAJBqKKYKEBZ1bgwILeG0Zf1k5+2I79SnWFA09jgVZ Q2dL95zpt19h3Kj3aaj8MNJx78ec/refTQ4sQhK5PweYaaN1DCJpuXX/e2kIL0sw1ANn JteA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=xfTR70zfndBehhefaoa9/t89dlmQpjwq/T4ehv3iQSA=; b=bDJQVI/k1FO4UcP05t8BPrrPA/wjtDx7nVnuXHIjuBSXAgZdcszAidx6VwF+9FN79a M4PUlYl+WtDCYcuIfphKEv+zWw8C4p7Lf2sV8ogQ5urlys7CPj2DQ+N83qNJYnJCVweK tbtU8n9tx4/GRgOPYxWMhEu/czKTl89z6Cu9rfti5LmPetX1zNN4+mdVcwkHxYffSXRz Ov28YnInIggJzcbIjfJt0S9i7dbGtz+po2Dj4rjQlM2OhrOiUvfT3X2T+/gaRYF/q1xp lIakR9t5AtP2s2N12zTieIy0ZPry/JVC4vmfew6/kLDxpUoo8/PN/OruVF6r0jVgTMd6 eFrQ==
X-Gm-Message-State: AIVw1127S3fqxOEMjWdFn5F7rEOfoJGXpIELSlg0abS0T89NGogDlnfy fm8Re+WuztcleCBHSKKXog==
X-Received: by with SMTP id t2mr17746293iod.160.1502663163716; Sun, 13 Aug 2017 15:26:03 -0700 (PDT)
Received: from sherlock ( []) by with ESMTPSA id 9sm2971617iom.3.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Aug 2017 15:26:02 -0700 (PDT)
From: "Mark Jones" <>
To: "'Benoit Claise'" <>
Cc: <>, <>
References: <> <>
In-Reply-To: <>
Date: Sun, 13 Aug 2017 18:26:02 -0400
Message-ID: <007b01d31483$26420ad0$72c62070$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01D31461.9F306AD0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFcBNgMiF2OgMpozWIFErACH22UAwCOMqiNo2v4LZA=
Content-Language: en-ca
Archived-At: <>
Subject: Re: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 (5084)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: AAA Doctors E-mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Aug 2017 22:26:07 -0000

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.




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


What do you guys think of this errata?

Regards, Benoit

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


[Technical Errata Reported] RFC6733 (5084)


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


RFC Errata System  <> <>




The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".
You may review the report below and at:
Type: Technical
Reported by: Priyatosh Mandal  <> <>
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.
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.
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