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

"Mark Jones" <mark@azu.ca> Sun, 13 August 2017 22:26 UTC

Return-Path: <mark@azu.ca>
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 74850133077 for <aaa-doctors@ietfa.amsl.com>; Sun, 13 Aug 2017 15:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=azu-ca.20150623.gappssmtp.com
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 umQ59vAsOY8A for <aaa-doctors@ietfa.amsl.com>; Sun, 13 Aug 2017 15:26:04 -0700 (PDT)
Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82EF01333E9 for <aaa-doctors@ietf.org>; Sun, 13 Aug 2017 15:26:04 -0700 (PDT)
Received: by mail-io0-x243.google.com with SMTP id h70so6617168ioi.2 for <aaa-doctors@ietf.org>; Sun, 13 Aug 2017 15:26:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azu-ca.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.107.145.2 with SMTP id t2mr17746293iod.160.1502663163716; Sun, 13 Aug 2017 15:26:03 -0700 (PDT)
Received: from sherlock (65-110-210-146.cpe.pppoe.ca. [65.110.210.146]) by smtp.gmail.com with ESMTPSA id 9sm2971617iom.3.2017.08.13.15.26.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Aug 2017 15:26:02 -0700 (PDT)
From: "Mark Jones" <mark@azu.ca>
To: "'Benoit Claise'" <bclaise@cisco.com>
Cc: <draft-ietf-dime-rfc3588bis@ietf.org>, <aaa-doctors@ietf.org>
References: <20170811040456.E8570B81789@rfc-editor.org> <4498890f-b043-8dae-a68a-cdf2c3137b9f@cisco.com>
In-Reply-To: <4498890f-b043-8dae-a68a-cdf2c3137b9f@cisco.com>
Date: Sun, 13 Aug 2017 18:26:02 -0400
Message-ID: <007b01d31483$26420ad0$72c62070$@azu.ca>
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: <https://mailarchive.ietf.org/arch/msg/aaa-doctors/ZJsxCxg4Fsb0lYHNcybtN_dvrKQ>
Subject: Re: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 (5084)
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=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.

 

./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  <mailto:rfc-editor@rfc-editor.org> <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  <mailto:priyatos@cdot.in> <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
.