Subject:	[Technical Errata Reported] RFC6733 (5084)
Date:	Thu, 10 Aug 2017 21:04:56 -0700
From:	RFC Errata System <rfc-editor@rfc-editor.org>
To:	vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, warren@kumari.net, jouni.nospam@gmail.com, lionel.morand@orange.com
CC:	priyatos@cdot.in, dime@ietf.org, rfc-editor@rfc-editor.org

Subject:

[Technical Errata Reported] RFC6733 (5084)

Date:

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

From:

RFC Errata System <rfc-editor@rfc-editor.org>

To:

vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, warren@kumari.net, jouni.nospam@gmail.com, lionel.morand@orange.com

CC:

priyatos@cdot.in, dime@ietf.org, rfc-editor@rfc-editor.org

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 <priyatos@cdot.in> 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 .

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 =E2=80=9CA Diameter entity issuing this =
AVP MUST create a higher value for this AVP each time its state is =
reset=E2=80=9D (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:aaa-doctors-bounces@ietf.org] On Behalf Of = Benoit Claise
Sent: August 11, 2017 05:05
To: = draft-ietf-dime-rfc3588bis@ietf.org; = aaa-doctors@ietf.org
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 = <rfc-editor@rfc-editor.org&g= t;
To:	vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, warren@kumari.net, jouni.nospam@gmail.com, lionel.morand@orange.com
CC:	priyatos@cdot.in, dime@ietf.org, rfc-editor@rfc-editor.org

The following =
errata report has been submitted for =
RFC6733,

"Diameter Base =
Protocol".

--------=
------------------------------

You may review the =
report below and at:

http://www.rfc-editor.o=
rg/errata/eid5084

--=
------------------------------------

Type: =
Technical

Reported by: Priyatosh Mandal <priyatos@cdot.in><=
/pre> 
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=C2=A0 =
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.
 
General=
ly 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=C2=A0 
can log in =
to change the status and edit the report, if necessary. =
 
-----------------------=
---------------
RFC6733 =
(draft-ietf-dime-rfc3588bis-33)
--------------------=
------------------
Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Diameter Base =
Protocol
Publication Date=C2=A0=C2=A0=C2=A0 : =
October =
2012
Author(s)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, =
Ed.
Category=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: PROPOSED =
STANDARD
Source=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Diameter Maintenance and =
Extensions
Area=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Operations and =
Management
Stream=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : =
IETF
Verifying Party=C2=A0=C2=A0=C2=A0=C2=A0 : =
IESG
.
 <=
/div>

------=_NextPart_000_007C_01D31461.9F306AD0-- From nobody Sat Aug 19 16:32:06 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD315132A1A for ; Sat, 19 Aug 2017 16:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQRNYDfYp-I2 for ; Sat, 19 Aug 2017 16:32:03 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 22927132153 for ; Sat, 19 Aug 2017 16:32:02 -0700 (PDT) Received: by power.freeradius.org (Postfix, from userid 1000) id ABAE72248422; Sun, 20 Aug 2017 01:32:01 +0200 (CEST) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.99.99) Message-Id: <20170819233201.ABAE72248422@power.freeradius.org> Date: Sun, 20 Aug 2017 01:32:01 +0200 (CEST) Archived-At: Subject: [AAA-DOCTORS] Automatic tech report for Sun Aug 20 01:32:01 CEST 2017 X-BeenThere: aaa-doctors@ietf.org 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: Sat, 19 Aug 2017 23:32:05 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-aaa-saml-14 In IESG processing - ID Tracker state draft-ietf-abfab-arch-13 In IESG processing - ID Tracker state draft-ietf-dnsop-isp-ip6rdns-01 Active draft-ietf-softwire-map-radius-05 Active From nobody Sat Aug 26 16:32:37 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861351321E6 for ; Sat, 26 Aug 2017 16:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq3f5eAtj-Nx for ; Sat, 26 Aug 2017 16:32:34 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id E5904126BFD for ; Sat, 26 Aug 2017 16:32:33 -0700 (PDT) Received: by power.freeradius.org (Postfix, from userid 1000) id 5534E224939B; Sun, 27 Aug 2017 01:32:02 +0200 (CEST) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.99.99) Message-Id: <20170826233202.5534E224939B@power.freeradius.org> Date: Sun, 27 Aug 2017 01:32:02 +0200 (CEST) Archived-At: Subject: [AAA-DOCTORS] Automatic tech report for Sun Aug 27 01:32:02 CEST 2017 X-BeenThere: aaa-doctors@ietf.org 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: Sat, 26 Aug 2017 23:32:35 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-aaa-saml-14 In IESG processing - ID Tracker state draft-ietf-abfab-arch-13 In IESG processing - ID Tracker state draft-ietf-dnsop-isp-ip6rdns-01 Active draft-ietf-softwire-map-radius-05 Active